Limitations for Enterprise to Enterprise replication
Ifyou wish to use SQL Remote for replication between Adaptive Server
Enterprisedatabases, rather than with Adaptive Server Anywhere remote
databases,you should be aware of the following limitations:
Databaseextraction Theextraction utility creates RELOAD.SQL
scriptsand data filesfor buildingAdaptive Server Anywhere remote
databases. Setting up remote ASE databases requires an extraction
processcreated by the customer.
Formore information about how to create an extraction process, see
“sp_remoteprocedure” on page 424.
Referentialintegrity errors Referentialintegrity is always checked
immediatelyin Adaptive Server Enterprise, while Adaptive Server
Anywhereprovides the WAIT_FOR_COMMIT option to control when
integrityis checked. This presents difficulties when rowsmove between
remotedatabases, as in territory realignment.
Forexample, suppose an Order table has a foreign key to a Customer
tablewhich has a foreign key to a SalesRep table. The Customer table is
subscribedby sales rep. The Order table is also subscribed by sales rep
(ithas a redundant column maintained by a trigger).
Whena row in Customer is updated to point to a new sales rep, a trigger
firesto update the sales rep column in Order. The update on Customer
isreplicated as a delete to the old rep and an insert to the new rep.
Similarly,the triggered update on Order is replicated as a delete to the
oldrep and an insert to the new rep.
Theproblem occurs because SQL Remote replicates the operations in the
orderthey occur, which means the Customer row is deleted before the
Orderrows. This causes a referential integrity error.
Schemaupgrades Schema upgrades are difficultto manage when both
consolidatedand remote databases are Adaptive Server Enterprise
databases. Passthrough to remote Adaptive ServerEnterprise databases is
difficultto carry out.
Theproblem is due to the need for a quiet system for schema upgrades
(see“Differences in functionality” on page 439). Passthrough puts
schemaupgrade statements into the normal message stream. The
operationsthat precede the schema upgrade (in the same message or a
previousmessage) cannot possibly have been scanned from the
transactionlog into the stable queue before the schema change takes
place.
442