Just spent several hours pulling my hair out (I don’t have much to start with) as to why when using a global variable in a ‘select field’ lookup, I was getting syntax errors in the generated PHP. Specifically a fatal error saying it had an unexpected ‘)’ on a line.
On examining the line in the generated code, it was apparent that the Scriptcase IDE generated incorrect PHP code if the entire lookup SELECT was a variable. (This MUST be a BUG!)
So, in summary …
Putting a full select in a lookup as native works fine (e.g. SELECT myID FROM MyProjects Where Project = ‘AAA’)
Substituting a variable for part of the select works( SELECT myID FROM MyProjects Where [P_Users]… in this case [P_Users] is a string “Project = ‘AAA’”
Substituting the entire select into a string [Lookup], makes the IDE generate incorrect code… in this case [Lookup] is a string “SELECT myID FROM MyProjects Where Project = ‘AAA’”
So my only workaround is option 2 above.
This might sound trivial, BUT… I have LOTS of similar lookups across a 200 app system. These lookups appear in multiple places on each individual app (main field, searches, groups, etc)… so to change a lookup is a massively inefficient (and very irritating) task, which occurs more often than you might think as a system evolves.
Normally you would do this in a ‘Proper’ data dictionary, but the Scriptcase data dictionary does not allow you to properly define a data element (In most DDs, you can create the lookup rules with the data element, because they are nearly always the same across ALL apps)
I’d planned on creating a pseudo dictionary with standardised lookup variables in a library so that I could have the lookup stored once as a string and then just use the variable names in all lookups. That way once the variables are setup in the relevant apps, you can change all occurrences of the lookup by simply changing the string in the library.
To make this ‘readable’ I wanted the WHOLE Select statement in a single place… as it happens(Due to the bug above), I cant do that… the partial string approach would work, but would make maintainability a nightmare.
I can only assume, the IDE code-generator looks for the SELECT and FROM bits of the lookup to parse something correctly. Since they don’t appear in the variable string untill it is used, it is causing the IDE to ‘tilt’
I hope this helps someone avoid the frustrations of my last few days.
Ian
PS… There is a similar problem with using variables for the connection string in sc_exec_sql($sql, ‘connection’)… connection cant be a string variable.