How to Solve System Errors in Source Code Generation

Scriptcase 8 Discussion
#1

I have a very complex control application with fields that have lookups into the database. SC have just tripped me up for the second time. For some reason the application can suddenly not be generated yet again. The first time it happened, I had to recreate the app step by step to find out what was wrong. It turned out to be that SQL code given for an automatic lookup may not contain an “select {field} as {label}”, although it is perfectly okay SQL. I wasted hours of work on that. Don’t use “… as {label}” for a column. Use a view instead where the columns can be given other labels.

The problem with these system errors during code generation, is that it is close to impossible to locate the reason. A pop up window states:

ERROR
System Error. We recommend you to send the file with the error to NetMake.
Log File successfully created: error_48e6a2c0bad426299c418b074b8200d5.html
Click on this link to send this error to NetMake.
Page with 1 queries,
DEL: 1created in 0.11s

There is no way to send the file to SC.

When you click the error html link, you get:
“Trying to get property of non-object | Script: C:\Program Files\NetMake\v8\wwwroot\scriptcase\devel\lib\php\database.inc.php linha: 1736”

Aha, you think. This is workable. I can open that file and find out where the problem is – not so!
The full file contents is:
<?php @Zend;
3074;
/*

Yes, three lines – there is no line 1736.

In the “Generated source code” page in the browser I can click the folder icon next to “Status: Error” and get this message:
“Fatal error: Call to a member function MoveNext() on a non-object in C:\Program Files\NetMake\v8\wwwroot\scriptcase\devel\lib\php\database.inc.php on line 1737”

Well, the file only contains three lines!!

This is just unprofessional. When serious errors like this happens, SC should make sure that one can locate the source of the error. Come on! Use some try-catch blocks and make sure that the generated source code is saved in a temporary file, which stays intact after the error occurs, even if the generation was not completed.

I am shaking with rage that I have to waste time on this yet again.

Does anyone have any idea if the temporarily generated code might be found so that the line numbers referred to can be checked?

#2

The file with the error is not generated, is a library used by SC. You can’t see it because is encrypted (security reasons).

What are you trying to achieve? I tried right now on SQL and on a lookup something like:
SELECT customerid, companyname as anotherfieldname
FROM customers
WHERE customerid = ‘{customerid}’
ORDER BY companyname

and works like a charm

#3

As for the problem with the SQL and lookup, that was the first time I had the code generation problem. The query was more complicated with joins and the error disappeared as soon as I removed the “… as {label}”. It must have been that specific SQL. The bad thing is that the error message had nothing to do with where the problem really was.

I have no idea where the problem is this time. I am not trying to achieve anything in particular that gives me the problem. The point is that my application suddenly cannot be generated as source code any more and the error message gives no clue as to what is wrong and where in the application the error is.

Even if it is a library used by SC, they should still give a more meaningful error message and a way to locate where the problem is. They could use a call stack and partly generated code or something. Anything else is unacceptable on SC’s part.

#4

I now found the problem by using the following procedure:

a. Use menu point “File -> Export Project” to make a backup of the whole project
b. Delete the fields one by one, and try to generate the source code after each delete
c. Once the source code can be generated, the problematic field has been found
d. Delete the application and restore it from the backup
e. Inspect the problematic field closely to find the cause of the error

In my app it was the SQL code in an automatic select lookup like earlier (but for another field).

The problem with the SQL is apparently use of tab characters for formatting rather than spaces. It works sometimes and sometimes not, giving problems with source code generation. Thus the first time I had the problem it was probably not the use of “{column} as {label}” in the select statement, which was the problem, but rather a tab character in that statement. I removed the “as…{label}” and at the same time removed the tab character. Now, the funny thing is that there are many other tab characters in the SQL statement. So sometimes it gives a problem, sometimes not. Best not to use tab characters at all for formatting, but instead use spaces.

I still think that SC should improve the structure of their source code generation so that error messages, log files, etc. are more meaningful and point to where in the application the problem arises. If SC use external libraries, they should have a trace on the point from which they are called, so that you as a developer with ease can find the problematic part in your own application.

#5

I hear your frustration and can relate to it as a three month user myself. Your experience goes down in my ‘tips’ book for best practice with ScriptCase. My strangest experience was learning that naming global variables should never be the same as a field name. Since this two day delay, I now have global variable naming convention that keeps that situation from happening again.
Best of luck to you. Know that most of us have been there.
Oh yes, thanks for sharing the resolution to your problem for the rest of us to learn from.
Ed

#6

You are welcome, Ed!

One thing that I should add in regards to the use of tab characters:
It is only a problem in SQL statements. In regular PHP code there is no issue.
Even in the SQL code it seems only to be a problem in the part of a select statement where the fields are specified.
However, it is safer to generally just use spaces in the SQL statements. Most editors can be configured to replace tabs with spaces.

Back on the horse being productive again, I must say that I am happy with ScriptCase in general.
It just produces functional and good looking applications with less effort!