forums › forums › SQLyog › Sync tools, Migration, Scheduled Backup and Notifications › two ways Synchronization didn't work
- This topic is empty.
-
AuthorPosts
-
-
June 7, 2004 at 1:25 pm #8459GlenMember
According to the SQLyog website, it is possible that you can configure SJA for TWO WAY synchronization. After using SQLyog I have considered the next problem.
I have two identical mysql databases on two different places. After I have changed some data in the both databases. I have run the synchronisation with SQLyog. I have noted the next problem, the change form the source database are transport to the target, but the changes form the target aren’t transported to the source. By the fact, the target database is identical to the source database now. <_< Could you explain what is going wrong or what did I wrong. I am looking forward for you response. p.s. I am using SQlyog 3.71
-
June 9, 2004 at 3:23 am #15909RiteshMember
SJA will always try to bring the target database in sync with the source database. If two rows have the same PK values then the target db will be updated with data from source.
You are not doing anything wrong. It is the way that SJA behaves.
-
August 4, 2004 at 8:32 am #15910ErianMember
I have a similar problem: I want to write the latest changes from one to the other DB, no matter which is defined as source and target – indeed you can't say one DB is the source and the other the target. I have a timestamp-column so I can identify which record is the newer one – but (how) can I tell SJA to check this timestamp and overwrite the old record?
thanks 🙂
-
August 4, 2004 at 11:09 am #15911ShadowMember
You should use the SQL WHERE option to make use of the timestamp column. Probably you'll have to write a script that modifies the job file before the sync.
-
September 3, 2004 at 9:36 am #15912summertimeMember
Here You can see the probs using the term “sync”. A timestamp-field alone is not enough for synching, because if a record was changed by three users, the “youngest” record must not be the right one.
Ex: if record-no. 171717 was changed by three users — user 1 changed tel.no. of customer, user 2 addes the street-address of customer and user 3 added fax-no of the customer. At every change also the timestamp-field changes —- but if Yog uses only the last change (the last “generation”), the changements of user 2 (street-address) would be lost and lost data should not happen at synchronisation.
Of course it's right, that after the Yog-sync both tables are identical, but both tables have also identical data-losses.
If both tables have (unique index) autoincrement and on both tables an insert produced the same key, which record is the “right” one? In this case, there are *two* right records. And if in an table you have 3, 4 or 5 unique fields, only a “real” sync function can handle this well. (And often has to ask the user for a individual decision, because automatic decisions can be often wrong.) Look at the experiences of synchronizing MS-Outlook data between two different devices — a 7 year old story of problems.
summertime
-
September 3, 2004 at 11:59 am #15913ShadowMember
Actually, you are the first who has problems with the naming of this feature. If you need such extensive sync options, then you have to turn to MySql's built in replication feature because it is the only one that can detect and handle changes so extensively using the binary log.. As I have mentioned preciously, SQLyog changes constantly and may once have such a feature that satisfies you taste.
-
-
AuthorPosts
- You must be logged in to reply to this topic.