SC Parse error

Scriptcase 7 Bugs
#1

I have a sql statement in a library like:

		$insert_sql = "INSERT INTO SCRIPTCASE.mutf_casestep (CASE_ID, CASE_FLOWSTEP, STARTDATE, REMARKS, " .
		              "EMPLID_CTRL, STATUS, CASE_FLOWSTEP_SEQ, EMPLID_CLAIM, SC_APPID, DEADLINE, ROLE_CTRL) VALUES ".
			          "('$caseid','".$rs->fields[2]."', TO_DATE('$datum', 'YYYY-MM-DD HH24:MI:SS'),'".$rs->fields[5]."', '".$rs->fields[3]."','WAIT', 0, ".
			          "0,'$appid', TO_DATE('$deadline', 'YYYY-MM-DD HH24:MI:SS'), '".$rs->fields[9]."')";

This parses well (after some fiddling).

“(’$caseid’,’”…

is changed to the casenumber as espected. However if you add a field like $rs->fields[2] in the same manner then wrong code is being generated. That’s why you have to split the sql statement and put the $rs->fields[2] outside of the string. So “where something > ‘$rs->fields[2]’” is not parsed correct and generates rubbish. This needs to be “where something >’”.$rs->fields[2]."’";

An error IMHO.

#2

Hello,

Is $caseid the same as {caseid}, or is it a variable you created that doesn’t map to an existing field?

regards,
Bernhard Bernsmann

#3

No, $caseid is a php variable which is parsed correctly. You can’t use {} variables in your library as there’s no screen. I even had trouble getting globals in, although I have working samples too. But in general I pass the variables in the header of the function call. But as soon as you use array variables in your library containing the [] the generation fails and a lot of odd stuff gets generated. In my case, complete sourcecode lines where put into the sql statement as paramets to send to the database (which went wrong of course).

#4

Hello,

I missed where you said it was a library.

Issue reported to our bugs team.

regards,
Bernhard Bernsmann