April 24, 2003 at 12:17 am
Hi,
We are (brand) new to replication and can't get past first base. We have set up Trans Replication and have selected to pass over Ref Int, Triggers, PK etc. However, all seems to go ok then the process stops with an error indicating a row cannot be loaded due to FK contraint problem. It was my understanding (but I can't find my reference now) that, during the initial load, data integrity checking is turned off, ie the data is assumed to be ok. If this is the case we shouldn't be getting this error.
We are stumped at the moment - any comments greatly appreciated.
Cheers, Peter
April 27, 2003 at 5:57 pm
Well we are passed first base but, unfortunately, we are not sure how. Our database has now been replicated to a second server - clearly we must have 'stumbled' into the correct setting - should have kept closer tabs on what we were trying but didn't of course.
We now have a problem that is more specific. When we change a row (using Enterprise Manager) the following error is generated:
"Another user has modified the contents of this table or view; the database row you are modifying no longer exists in the database"
Followed by another error message:
"DB error: [MSoft][ODBC SQL Server Driver][SQL Sever] Maximum stored procedure, function, trigger or view nesting level exceeded (Limit 32)"
This error occurs on any table change. At our simplest level the change was on a simple code/name table (no relationships) and we just tried to change the name. All the tables in the database have four standard columns:
XXXCreateDate
XXXLastUpdate
XXXUpdateCount
XXXTimestamp
and an update trigger that updates XXXLastUpdate and XXXUpdateCount each time a row is changed.
So there is a trigger involved but no other users are accessing this database.
TIA - Peter
April 27, 2003 at 11:26 pm
OK - by deleting the XXX update trigger the error goes away. Further research revealed what seemed to be the answer - insert the line:
NOT FOR REPLICATION
just before the "AS" in the trigger. This we did and created another replicated database from scratch but we still have the same error coming up.
Is there something else we need to turn on/off to disable these triggers? We can't remove them from the replica because its our warm standby database, ie if the dataserver fails this is the database that will be used in production.
TIA - Peter
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply