Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 2 of 2 total
Thread Replication.
Fri, Dec 21 2018 4:27 PMPermanent Link

Steve Gill

Avatar

I looked at implementing database replication a couple of years or so ago but never got around to doing anything serious.  A couple of weeks ago I decided to start doing some work on this.

I have found that when the job I created starts saving the updates, the application stops responding and I end up getting an ElevateDB Error #300 because the database engine "Cannot lock the table xxxx in the schema Default for transaction access".

It doesn't matter how frequently or infrequently I set the job to run.

So I assume what's happening is that the save updates process is putting a transaction lock on the tables being replicated, which prevents the application accessing these tables.

Has anyone else experienced this and, if so, did you find a solution?

Thanks.

= Steve
Thu, Jan 3 2019 12:13 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Steve,

<< So I assume what's happening is that the save updates process is putting a transaction lock on the tables being replicated, which prevents the application accessing these tables. >>

Yes, that is correct.  However, the process of saving the updates should be very quick and you shouldn't even notice it.

How many updates (approximately) are being logged/saved when this occurs ?

You can use the CREATE TEMPORARY TABLE FROM PUBLISHED UPDATES/FROM UPDATES <UpdateFile> to determine how many updates are being saved/have been saved to a particular update file:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=CREATE_TABLE

Tim Young
Elevate Software
www.elevatesoft.com
Image