Hi all,

one thing i expected to have automatically with Dev Studio was automatic syntax checking on all code syntax.

There are currently lines of code you can enter that won't be checked for syntax and therefore if mistyped can produce the wrong result.

The code I'm referring to is:

ENGINE SQLORA SET DEFAULT CONNECTION ....  

I had mistyped 'connection' but instead of informing me of this it used the existing default connection. The point of declaring a new default connection is to override the existing default so i would expect syntax checking to be carried out on this line of code, so for a while i was scratching my head as rtoi why i wasn't getting the right data.


has anyone experienced this? or got any opinion on whether this should be fixed or not?

im just checking that 765 has the same problem...

Syntax checking is done at run time. To ensure that the program does not continue to run despite errors, I always add the following (or a variation of) after every complete command:

...

-RUN
-IF &FOCERRNUM NE 0 GOTO FOC_ERROR;

...

-EXIT

...

-FOC_ERROR
-SET &ERR_MSG = FEXERR(&FOCERRNUM,'A72');
-TYPE WEBFOCUS ERROR: &FOCERRNUM - &ERR_MSG
-EXIT

If you have code like this after your ENGINE command, the program will not continue.

To test the code without actually retrieving data, add

SET XRETRIEVAL=OFF
-RUN

at the beginning of the program.

Developer Studio can't do any of this automatically through GUI tools.

This message has been edited. Last edited by: Francis Mariani,

Hi Francis,

Thanks for your reply i will definitely have to start utilising my own error checking to catch this, also thanks for the xretrieval code- very very useful!!!

do you think then that this line shouldn't be included in any WF syntax checking as its parsed? it seemed odd to me that it has been set up to ignore checking these statements but thats not to say there isn't a good reason for it....

The line is most likely not ignored - I'm sure you get an error if the syntax is wrong. What will happen though, is that the program will continue running the rest of the code, unless you trap the error.

I run the following command:

ENGINE SQLMSS SET CONNNECTION_ATTRIBUTES  AA/CC,EE

I get the following error:

 (FOC1400) SQLCODE IS 195 (HEX: 000000C3) XOPEN: 42000
 : Microsoft OLE DB Provider for SQL Server: [42000] 'CONNNECTION_ATTRIBUTES' is not a recognized SET statement.
 (FOC1414) EXECUTE IMMEDIATE ERROR.

quote:

The line is most likely not ignored - I'm sure you get an error if the syntax is wrong

Francis hit the target on this one- WF is always going to try to complete the code as much as possible. Sometimes the error it gives are warnings like PRINTPLUS DISABLED, but still continues to process if it is able. If you -SET &ECHO=ALL; you would see the error message you are looking for, but it doesn't stop WF from trying to complete the stacked code. I've had instances where DEFINE syntax was incorrect, but I hadn't used that field yet in the table request, so I can see the error, but my code still completes. If I add the incorrectly defined field to the table request, the code crashes and the errors become obvious.

Part of my testing ALWAYS includes a complete review of the processed code using the ECHO command or the Message Viewer (although I've found that the DS Message Viewer sometimes leaves out code - especially when fields are inserted into HEADING, SUBHEADING, FOOTING, SUBFOOT, etc.)

Darrin Lee,

I've discovered, through experimentation, that DEFINEs are ignored unless the DEFINEd column is actually mentioned as a PRINT/SUM column. WF is interpreted and compiled dynamically 'on the fly'. It's efficient to not process unmentioned definitions. Similarly, I suspect simple syntax errors in *.mas are ignored unless the field is actually used in the *.fex.

Chris

quote:

The line is most likely not ignored - I'm sure you get an error if the syntax is wrong. What will happen though, is that the program will continue running the rest of the code, unless you trap the error.

Francis

The line i used that didn't get picked up was

default_connetcion instead of default_connection, rather than throwing upo an error it used the existing default and gave me the wrong (or right, depending on how you look at it) data.

must test this with 765

quote:

Originally posted by Darin Lee:

quote:

The line is most likely not ignored - I'm sure you get an error if the syntax is wrong

Francis hit the target on this one- WF is always going to try to complete the code as much as possible. Sometimes the error it gives are warnings like PRINTPLUS DISABLED, but still continues to process if it is able. If you -SET &ECHO=ALL; you would see the error message you are looking for, but it doesn't stop WF from trying to complete the stacked code. I've had instances where DEFINE syntax was incorrect, but I hadn't used that field yet in the table request, so I can see the error, but my code still completes. If I add the incorrectly defined field to the table request, the code crashes and the errors become obvious.

Part of my testing ALWAYS includes a complete review of the processed code using the ECHO command or the Message Viewer (although I've found that the DS Message Viewer sometimes leaves out code - especially when fields are inserted into HEADING, SUBHEADING, FOOTING, SUBFOOT, etc.)

i think using francis' idea is what ill have to use as spotting a one letter typo is sometimes hard with pages of code, using my own syntax check to make sure WF is reading my code properly should give me back the functionality i require...

cheers all

As in many languages, there are several levels of errors such as warning and critical to name but two. Generally warnings will allow processing to continue with messages or error codes set (i.e. FOC401), where as critical errors would cause the processing to be stopped immediately (i.e. FOC205).

I'm sure that Leah and Ginny ? could recount how, on mainframes, and using languages such as Cobol, program runs had an acceptable error code value, beyond which the process would be aborted.

I would hazard a guess, from what you've mentioned, that you have a "standard" default connection set in the server profile or somewhere. Therefore I would envisage that because a default connection is in force, your coded one would have just been ignored (with an error code set somewhere?) and processing would have been allowed to progress? Francis' error checking is based upon events such as this.

I know that the trend nowadays is to skimp on the error vetting code within programs but the base language will only be written to do internal error checking, to establish if processing should continue or not depending upon whether all required configuration etc. is available.

I know that I am guilty of not always using error checking, but hopefully I include it where absolutely necessary

T

Yes, Tony, you are correct. COBOL compilers always gave 3 types of messages, W for warning, C for caution, and E for error. If you had E's, the program couldn't be linked so there was no executable. One strove for only W's.

As for Nubi's problem, if there is an error in a connect string as he states, often the error shows up somewhere later in the program. For instance, if the program was creating a hold file for further reporting and the initial query failed because of the connect string error, you would get a file not found on the hold file and the program would fail. It sometimes takes a little detective work to figure out what the 'real' error is.