There are two situations where I do not find this convenient : 1) I have to copy Master table records to the destination database so I can compare values in all fields to "decide" if they must be merged at first (if I want to do this using SQL). 2) For many tables, I wish to let the user decide (after visual inspection) if they want to merge some records. And this is not always after a database merge, it is more often simply the result of end-user error (they created 2 records for the same thing and want to merge them).
What I did in situation #1 was that I transferred all (Master and Details records) and merged afterwise using a stored proc updating all FKs for complex tables. In other situations, I made a program with connections to both databases to compare and transfer with the updated value ... otherwise the udpate would be too long Stored Procedure updating all FKs do the job, it sure is more efficient than coding it for each table (Users ID are referenced by over 240 FKs through the de database), but there must be one flavor for each field type. This is not as convenient as a cascade performed by the server would be ... especially if http://tracker.firebirdsql.org/browse/CORE-4348 (be able to determine if update was triggered by a cascade) is implemented (and I hope it will). > -----Message d'origine----- > > > If I understood this, why you didn't use cascade foreign keys on the > base tables and update them before the merge? > > > Adriano ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
