In 4D 2004 there are sixty-nine Command Syntax Errors documented in the 4D Language Reference:https://www.4d.com/4ddoc2004/CMU/CMU02022.HTM. In 4D v11 SQL there are eighty-one Command Syntax Errors documented in the 4D Language Reference:https://www.4d.com/docs/CMU/CMU02022.HTM. Developers need to be ever more conscious of their syntax since 4D will now throw an error on many old habits. The new Command Syntax Errors are:

• 70  The command cannot be applied between two Picture arguments.
• 71  The SET PRINT MARKER command can only be called in the header of a form being printed.
• 72  A pointer array was expected.
• 73  A numeric array was expected.
• 74  The size of arrays does not match.
• 75  No pointer on local arrays.
• 76  Bad array type.
• 77  Bad variable name.
• 78  Invalid sort parameter.
• 79  This command cannot be executed during the draw of a list.
• 80  Too many query arguments.
• 81  The form was not found.

Let's look at one way to handle the new error codes, focusing on error code #81: "The form was not found". It is documented in both the 4D 2004 and 4D v11 SQL Language Reference the following:

"The default input form is defined in the Explorer window for each table. This default input form is used if the INPUT FORM command is not used to specify an input form, or if you specify a form that does not exist".

The same statement is made about the command OUTPUT FORM. In a table with many forms it may become burdensome to try and remember which forms are designated as the defaults for use in the commands INPUT FORM and OUTPUT FORM. Since there is no programmatic way to determine which table forms are the default input and output forms, a way to make 4D use the default form was to assign a form that was known not to exist, e.g. INPUT FORM([myTable];"n/a").

Prior to 4D v11 SQL, 4D handled such an assignment without a complaint. In 4D v11 SQL such an assignment throws an error #81. Does that mean 4D v11 SQL does not handle the assignment in the same way? Not at all! With such assignment 4D v11 SQL, like its predecessors, will use the forms assigned as the default forms in the Explorer. To take care of the error that is going to be thrown because of this assignment, the developer now has to account for it in an "Error Handler".

If you have a large general error handling method, the solution could be as simple as adding a case statement such as:

Case of   :(Error#81)     ALERT("Error #"+String(Error))   :(Error=81)     `// Do nothing End case

Optionally you could create a dedicated error handling method such as:

If(Error#81)   ALERT("Error #"+String(Error)) End if

Install that using ON ERR CALL just before making the form assignment. This technique is demonstrated in the documentation to the ON ERR CALL command at: https://www.4d.com/docs/CMU/CMU00155.HTM.