Smartlist is outsmarting me

[Andreas Pfeiffer]

Hi Uwe,

Happy New Year.

You could override $doinsert (note – without the ‘s’) and see if you are able to track the error there. $doinserts calls $doinsert for every row where the $status is set to kRowInserted.

Hope that helps.

Best,

Andreas

[Uwe Smidt]

Hi Andreas,

Happy New Year to you, too!

My $doinsert is overridden in taSuper, but

Do llAggregierteZaehlerstaende.$dowork()

(or $doinserts) does not care to fire – it does not ‘catch’. When I step in, it just steps over.
However, I’ve added some lines, merging llAggregierteZaehlerstaende into llZaehlerstaende, and now it works on ‘Do llZaehlerstaende.$dowork()’:

Do llZaehlerstaende.$smartlist.$assign(kTrue)
Do llZaehlerstaende.$merge(llAggregierteZaehlerstaende)
Calculate lbSmart as llZaehlerstaende.$smartlist ## is it still smart(enough)? YES
Do llZaehlerstaende.$includelines(kRowInserted) ## are there lines to be inserted? YES, all 747 lines
Do llZaehlerstaende.$dowork()

[Uwe Smidt]

So the main instance is $dowork’able, but the correctly created ‘sub’ instance llAggregierteZaehlerstaende is not.

Is there an explanation for this behaviour?

[Andreas Pfeiffer]

Uwe,

If the method is not called I would think that there is no record where the status is kRowInserted. Check $status of an inserted row.

Best,

Andreas

[Uwe Smidt]

Thanks for the hint:
Calculate liStatus as llAggregierteZaehlerstaende.$history.1.$status ## Status is 8: kRowInserted
So the first line has Status kRowInserted, and

Do llAggregierteZaehlerstaende.$includelines(kRowInserted) ## are there lines to be inserted? YES, all 747 lines

says that there are 747 lines to be inserted!

[Uwe Smidt]

It seems like Omnis considers llAggregierteZaehlerstaende not to be ‘worth’ considering the $dowork-method, like it is not $smartlist, or not even defined from an SQL class.

Is the a way the check the ‘status’ of a list, i.e. is it a SQL class-based list?

[Uwe Smidt]

Problem solved – still a bit of a mystery left…

Problem was that I defined the list from a schema class:

Do llAggregierteZaehlerstaende.$definefromsqlclass($schemas.tnZaehlerstaende) ## create a list based on the the same schema

While the Documentation says

You create a table instance in Omnis when you define a list or row variable from a schema, query, or table class, using the Define list from SQL class command, or the $definefromsqlclass() method.

it appears that defining a list from a schema is good practice. However, reading on, there are subtle differences:

Table instances created from a table class have all the default methods of the table class in addition to any custom methods you have added, perhaps to override the default methods.

And yes, in my table super class taSuper, I have overridden all the default $dowork etc methods.

So changing one line of code to

Do llAggregierteZaehlerstaende.$definefromsqlclass($tables.tanZaehlerstaende) ## create a list based on the the same table class, NOT schema!!!

did the job!

Long live the small subtle differences in Omnis that make big differences!

[Uwe Smidt]

PS: I missed out on the mystery part:

I have not tested if all would have worked fine when using a schema class for definition, with the default $dowork still in place.

[Diego Mendoza Muñoz]

Pequeño comentario al usar iList as $cinst estas anulando el uso real de la clase tabla, estas usandolo como una clase object, no seria mejor usar clases objetcts?? podrias crear el metodo getDefinedList, creo que te simplificaria, no tendrias que estar haciendo override y seria mas claro. anexo un proceso que yo uso con un helper de uso generico

——————-
A small comment: when using iList as $cinst, you’re canceling the actual use of the table class; you’re treating it like an object class. Wouldn’t it be better to use object classes? You could create a getDefinedList method; I think it would simplify things, eliminate the need for overriding, and make things clearer.
I’ve attached a process that I use with a generic helper.

• This reply was modified 2 weeks ago by  Diego Mendoza Muñoz.

Captura.png 7 KB Image File - Click to view

Options

• Copy Download Link

[Diego Mendoza Muñoz]

Comentario aparte, usa la clase table como un modelo de entidad, o sea validaciones de negocio, por ejemplo precio no puede ser mayor al costo, tiene que tener email, no como un manager de base de datos, si usas un objeto usalo como modelo, entonces al momento de mandar un insert, iList (table class)
if iList.$validate()

iList.$dowork() returns flagOk

if flagOk

else

notificationManager.$showOnScreen(iList.$statementobject.$nativeerrortext)
end if

else

notificationManager.$showOnScreen(iList.$getErrorText())
end if

[Uwe Smidt]

Hi Diego,

Thank you for your ideas.

I’m afraid I could not really put the puzzle pieces together for me 😳.

Best regards

Uwe