Handling Returned Errors
- Last UpdatedJan 07, 2026
- 3 minute read
Errors which can be trapped and handled specifically by Query may result in one of the following error messages (where info represents any supplementary information about the error which is generated by the data server or the communications software).
Server Daemon Messages:
|
(79, 3) |
Cannot initialize server daemon: info |
|
|
For example, the server daemon executable cannot be found via any of the expected directory paths |
||
|
(79, 4) |
Cannot connect to data server: info |
|
|
For example, an invalid password has been used |
||
|
(79, 5) |
Cannot send request to data server: info |
|
|
For example, a networking problem has interrupted communications (info will show the request that has failed) |
||
|
(79, 6) |
Error returned: info |
|
|
Reason appended to the message by the data server |
||
|
(79, 7) |
Request failed: info |
|
|
For example, an invalid data server command has been entered |
||
|
(79, 8) |
Cannot fetch next row: info |
|
|
For example, a network interruption or a data server error has occurred while waiting for the result of an EXTERNAL GET ... NEXT request (see Setting Variables from the Data Server Responses) |
||
|
(79, 9) |
Command is too long |
|
|
The command has exceeded the limit of 4095 characters (don’t forget the separating spaces when summing the lengths of the individual command strings) |
||
|
(79, 10) |
No more data |
|
|
For example, the most recent EXTERNAL GET ...NEXT command has failed because there are no more rows of data to retrieve. This is a very useful error number to trap, since it allows the user to use an infinite DO loop to retrieve consecutive rows from a table of any length and then to escape when all the rows have been read; the user will find an example of the syntax for doing this in Section Setting Variables from the Data Server Responses. |
||
The text of a data server error message is usually explicit, since it is generated from the database, and so its meaning, and the method of resolving it, should be clear. For example, if the user is communicating with an ORACLE database, the command
EXTERNAL SEND $!!MAINT ’select * from emp’
could result in the error
(79, 7) Request failed: ORA-00942: table or view does not exist
Similarly, the command
EXTERNAL SEND $!!MAINT ’select * from emp’
could result in the error
(79, 7) Request failed: ORA-00904: invalid SQL statement
Communications Software Messages
Note: These are most likely to be caused by general network problems rather than by Query itself.
|
(79, 51) |
Cannot initialize remote process query |
|
|
(79, 52) |
Connected to data server (for information only - cannot be released) |
|
|
(79, 53) |
Data server released (for information only - cannot be released) |
|
|
(79, 54) |
Cannot set delimiter character: info |
|
|
(79, 55) |
Cannot terminate server daemon: info |
|
|
(79, 56) |
Daemon file incorrect or missing |
|
|
(79, 57) |
Unknown daemon synonym: info |
|
|
Check that the required synonym has been entered correctly and that it is included in the daemon_file |
||
|
(79, 58) |
Cannot toggle tracing in server daemon: info |
|
|
(79, 59) |
No licenses available for remote process query |
|
|
The maximum number of communication channels (daemons) permitted by the users license are already open. Close an unwanted channel if possible |
||
|
(79, 60) |
Remote process query security error: info |
|
|
Contact AVEVA Support for advice |
||
|
(79, 63) |
Server daemon has shut down because a FATAL error was detected |
|