04-16-2019 05:16 AM - edited 04-16-2019 05:33 AM
Using GMSC 2016.03.
I have a list with an action for every row that sets the feature active in GMSC, sets the element as selected and zoom to it on the map.
For all my other layer, the action work perfectly fine with the following code:
However for two layers it does not work quite properly:
The only things that differs here is the fact that both layers havethe same database table as source but with a different attribute-based filter: there are two types of object in the table and the client decided to register them as 2 separate features instead of using a filter at the symbology level.
I am wondering if there might be some interference between the two.
Has anyone had a similar experience?
or is there something else I could check/change to pinpoint the problem?
PS: log file was not helpful...
04-16-2019 07:40 AM - edited 04-16-2019 07:40 AM
the JS API has changed, it is asynchronous, with your action specification there is no guarantee the methods are executed in that order. Please check the following tutorial:
05-20-2019 02:48 AM
I tried your solution with GMSC 2016.03 and I cannot bring it to work.
I tried with the IG. and the SC. version.
As mentioned earlier my code works fine for 10 other features.
What I noticed is that the ID of the object saved in the SEC_SESSION behaves strangely.
Sometimes it is saved as an integer and sometimes .0 is added to the ID (see image), sometimes it is saved with the name of the schema (Oracle DB) and sometimes not. Might it be that there is a problem here?
The ID-column has the following datatype: NUMBER
Any ideas of what I could try next?
05-20-2019 03:41 AM
the schema is part of the session variable if it is set in the feature settings. No idea how that .0 is added to the pk value. Please try:
you should get the value in the session in the proper way.
As said your way to define the action may even work in 99% of the cases, but there are no guarantee it will always work.
05-24-2019 02:07 AM
05-24-2019 02:15 AM - edited 07-09-2019 07:13 AM
that is indeed my next step: change the datatype in Oracle from NUMBER to NUMBER(18,0) for the PK-field. I will come back and confirm if this works for me as well.
[UPDATE] Changing the datatype as mentionned above solved the problem