At 12/22/2001 01:05 AM (Saturday), Claudio Valderrama C. wrote:

> > While on the subject of the parser, I would sure love to see the
> > identification of tokens in error messages done in terms which are more
> > useful to the user. The "line X, character Y" counting is very difficult
>to understand!
>
>Please explain what you mean.

Everyone I know who has worked with triggers and stored procs in Interbase
has had trouble identifying exactly where the errors occurred when
Interbase reports an error. They usually come to me for help determining
where the counting starts from. It certainly does not start counting lines
at the beginning of the script file being processed (which is everyone
seems to expect and what I'd like).

Also the character positioning treats tab characters as one char which
confuses some people.

Finally, the character positioning does not point to the beginning of the
offending token, or alternatively to the end of the offending token, but to
the end of the preceding token. Either of the first two choices would be
more helpful.

Here is an example from a IB 5.6 WISQL script output:
CONNECT
'C:\Program Files\InterBase
Corp\InterBase\examples\database\EMPLOYEE.GDB' user 'SYSDBA' password
'masterkey';
COMMIT;
SET TERM ^ ;
ALTER PROCEDURE ADD_EMP_PROJ (EMP_NO SMALLINT,
PROJ_ID CHAR(5))
AS

BEGIN
BEGIN
INSERT INTO employee_project (emp_no, proj_id) XXX (:emp_no, :proj_id);
WHEN SQLCODE -530 DO
EXCEPTION unknown_emp_id;
END
SUSPEND;
END
^

Statement failed, SQLCODE = -104
Dynamic SQL Error
-SQL error code = -104
-Token unknown - line 7, char 49
-XXX
COMMIT^

The "Line 7" makes sense only if you understand it is line 7 of the stored
proc when you count the ALTER PROCEDURE line as 1. It would be more useful
to identify it as line 12 of the script. That way I can have my text editor
go directly to line 12.

The "char 49" points to the right paren following proj_id. This is NOT the
problem token. It should report "char 51" as the problem, or maybe char 53.

This is not the best of examples since XXX stands out as an error and is
easily seen. However, if the offending token was an identifier which is
used throughout the procedure it becomes a bit more difficult to find. This
is especially true when working with a parser which doesn't match your
expectations of identifying correct syntax.