Is it possible to query an array of pointers?

[guiroehe]

Hello,

I wonder if FlexSim does allow to query an array of pointers (no reason why not), and how.

I tried to do a simple example with an array

A = [/ptr1, /ptr2]

However,

Table itemsInformation = Table.query("SELECT $2 AS [item], $3 AS [myProperty]  FROM $1 ", A, $iter(1), $iter(1).myProperty);

 Returns an array with null pointers in the first column, despite returning the correct label values in the second.

Is there something I am missing, please?

[jason_lightfootVL7B4]

I would instead use:

Table t=Table.query("SELECT $2 as item, item.myProperty FROM $1",A,$iter(1));

or you could have:

Table t=Table.query("SELECT Object, Object.myProperty FROM Objects() WHERE Object IN $1",A);

If you have null pointers then that suggests the items have been deleted since the query was run.  You might prefer to record a unique id for each flowitem.

[joerg_vogel_HsH]

How to query an array 

[guiroehe · Accepted solution]

Hello, @jason_lightfootVL7B4 and @joerg_vogel_HsH ,

It turns out there is some type of memory leak on FlexSim's SQL engine. All solutions you presented (and mine as well) work.

However, once there is a fail on a SQL statement (typo, ill formed string, ...) the engine stops behaving correctly.

I tried your solutions and they did not work at first. Once I closed all FlexSim instances and re-opened FlexSim, lo and behold, all versions worked fine.

Thank you for your attention.

[joerg_vogel_HsH]

@guiroehe , this is something that I have observed right from the beginning, when SQL has been introduced as a feature. It is hard to get any attention to this problem, because a valid clause works after opening a new session. Once an error occurs many valid clauses are causing new errors. And when you send in a model, it isn’t faulty at all. It is a sequence of steps that leads to this bug. Thank you for your description here.

[jason_lightfootVL7B4]

Gui has this been reported/recorded elsewhere by a member of the team?

[guiroehe]

@jason_lightfootVL7B4,

yes, many of them reported the same issues. However, as you mention it is hard to replicate exactly after the software is closed, so a mention is usually followed by some comment like "one of those things with FlexSim..."
What I can add is that:

- using ill-formed clauses in queries as code in activities (e.g. custom code activities) usually causes this type of problem, often a complete crash with the abortion of the application (FlexSim) by the OS. Sometimes a simple typo on the name of a column table or label will cause this.

- if FlexSim is not aborted, the SQL engine might start behaving inapropriately

- one factor that often triggers these problems is when one uses a breakpoint and, by mistake (?), changes the code without first finishing the process execution

None of the items above is a sure cause for the observed effects, but those are the common reports I observed.

I hope this helps.