I'm in the process of sending a new trigger to a table on our replicating databases.
Environment. SQL Anywhere 12.0.1 Build 3942
The only job of this trigger is to make sure if it gets back a '' blank value in a specific column, to change it to null.
Made change on consolidated database. No issues. Trigger functioned just like it should.
Here is my passthrough...
In the trigger I'm using the "if current remote user is null then" test, so triggers don't fire triggers. So I'm not hitting a loop.
However, right before I sent this passthrough into the queue, I cleaned up 11 rows in the companies table that had a blank value instead of a null value. I believe I was connected as dba when I did that.
This ran correctly on the consolidated side, and when I ran replication, it ran correctly on that side as well.
However, when it got to creating the trigger on the replication database side, I started getting the following in the log created on the replication side...
So now I have this passthrough, along with two other passthroughs stuck in the queue.
Are there any way to tell the databases to ignore anything after a particular offset?
Any suggestions would be greatly appreciated. As you can tell, I followed all the correct rules and ran my passthrough a test machine first.... NOT!!!!
So now I've gummed up the works.
Thoughts on direction anybody would be appreciated!
asked 01 Aug '16, 19:12
Jeff, I'd initially thought that maybe the clean-up just before the passthrough might be holding the
I can’t see the same problem you’re seeing. I’d initially thought that maybe the deletes on the table in the same session could be holding the lock, but I think the attached repro does the same thing you did to the Child table in my sample, and it run with no issues. Does this repro do the same thing you did? To run the repro, unzip the contents of the ZIP into an EMPTY directory, open a DOS prompt, CD to the directory where the files exist, make sure SQL Anywhere v12 is in your path and then type “rep”.
If you can repro this, I’d love to be able to turn on request level logging for the database engine before SQL Remote runs so we can look back in the log and see who might have acquired a lock on the table in the process. Getting the output from sa_conn_info() when the error occurs would also be handy, but I recognize that would be tricky since you'd need to execute it at the time SQL Remote was runnign and got the error.
answered 02 Aug '16, 14:26