We are running dbremote.exe against a remote and consolidated database. We are intermittently getting the error:
when running replication. The funny thing is we do not have a table or reference a table called 'request_queue'. We thought this might be a system table, but could not find it using:
We are wondering if this is a temporary table that is created by dbremote.exe whilst it is running and, if so, how this relates to the errors we are getting and what might be causing this? When the skipped SQL is run into the database in iSQL, no errors are reported and the inserts complete successfully.
In case it's relevant, we are running dbremote.exe on the consolidated database as a client connection (over TCP/IP) from the remote laptop.
The relevant parts of the log file follow below:
Thank you everyone. After translating the log file, and from the helpful comments, answers and suggestions, we have now identified that this is being caused by a trigger calling a stored procedure under some rare circumstances, which references the non-existent 'request_queue' table. As suggested, it was being caused by a trigger calling a stored procedure. Both were written around mid-2001 by the original developers who have long since left the project. We now trying to work out why the trigger and stored procedure were included at all, as they don't appear to be required for anything. It does look similar to what Breck suggests as an old, early 2000s, technique, similar to Rob Waywell's presentation.
The message was "table not found" so it's not surprising that sysobjects doesn't contain it [snork].
Look for references inside all the stored procedures and triggers
BEGIN SELECT * FROM SYSTABLE WHERE view_def LIKE '%request\_queue%' ESCAPE '\'; SELECT * FROM SYSPROCEDURE WHERE proc_defn LIKE '%request\_queue%' ESCAPE '\'; SELECT * FROM SYSTRIGGER WHERE trigger_defn LIKE '%request\_queue%' ESCAPE '\'; SELECT * FROM SYSEVENT WHERE source LIKE '%request\_queue%' ESCAPE '\'; END;
Request_queue may be a reference to an application table left over from an old (circa 2000) technique used with SQL Remote; see slide 56 of Rob Waywell's PPT here. ...perhaps with ssremote.
In addition to Breck's observations and since this is occuring while applying a message (and given the single statement context involved is an insert into your "DBA"."DEVICE" table) I would recommend look into triggers defined on that object and any procedures, functions, or other table object referenced there (and triggers on any table objects referenced by/cascaded from those ... etc. )
Probably the quickest way to identify the exact source of this error would be to capture it in a request log. By using either -zr all (with -zo) or calling sa_server_option( 'requestlogging', 'all'), you should be able to get at the exact PSM-capable object and statement that is throwing this error.
This error is basically being thrown at the time of semantic and syntactic checking (during annotation) so it could only be caused by a single SQL statement being executed somewhere.
As far as I know, there is no table/view/procedural object with a name like "requrest_queue" anywhere in SQL Anywhere so I have no reason to believe this is any internally used/managed object. A malformed string passed to an Execute Immediate might be able to randomly produce such a string ... but that would still need to be identified from a request log.
Of course, the biggest concern is not these skipped operations, but what those operations should have been and whether or not that represents a loss of data/synchronicity.
Best of luck.
answered 24 Jan, 09:18
Nick Elson S...