Synchronize without checksums?

[james3]

The data in my rows is unlikely to change — if it is there, it is correct. Computing checksums is uneeded — I would just like to update a row if it is missing in the target database. Is there a simple way to do this with SQLyog?

[Ritesh]

If we dont generate checksums, there is no way to compare the data without bringing the entire data to the client.

[james3]

I was thinking of just going through each row and saying “Does this primary key value exist in both tables? If not, get the row and add it to the target database.” I could write a small program to do that easily enough — I was just wondering if the function might be built in to SQLyog.

[Shadow]

Yeah, that's a good idea! In our db there is a table containing log entries which must not change, only new entries may be appanded. As this table is pretty large, its sync takes a ehile. Such feature could considerably reduce the overhead of the sync in this case…

[summertime]

I think that the word “sync” is used often too early too often; even specialized progs like access2mysql sync or dbcopy 2.0 are even “semi-sync” progs.

Sync or synchronizatin means usually, that after a sync of 2 tables / databases every of those 2 tables/databases have the same data — as You have at a replication after a “sync”.

So I mean, that Yog has not a (real) sync-function and I wouldn't expect from Yog to became a sync-tool. It's a high-end administration tool.

summertime

[Shadow]

Are you going to contribute some useful advices or keep playing with words? Who cares what syncronization 'usually' means as long as we understand what the other person is talking about!

Quote:

that after a sync of 2 tables / databases every of those 2 tables/databases have the same data — as You have at a replication after a “sync”

SQLyog's data sync tool does exactly that!

[summertime]

Hi shadow,

my information is about 6 month old. With the last release of Yog we never tested that. After we tested – 6 month ago – (beside other progs) the (real) synchronisation between MS-Access-tables and mySQL-tables, there were different problems which I cannot remember all.

One problem – I remember – was, that the sys-fields of MS-Access-replication (GUID, etc.) blocked synchronisation. After testing several progs we decided at the end for this task to buy the prog Access2Mysql Sync. It was the only prog which handled the replication-fields of MS-Access. And even that prog hat probs to convert MS-Access fields into mySQL-fields and vice-versa.

Can it be, that the Yog-synchronisation works only between two mySQL-tables?

One prob – I can remember – was, that Autoincrement-fields made a lot of probs. Beside that there are / were problems at synchronisation which had to do with mySQL/MS-Access incompatibilities (logical fiels vs. tinyint or set/enum-fields, etc.)

But we use Yog because it has advantages not seen by others: e.g. copy a data-base to another host, 3 connected databases on different hosts at the same time, ….

Regards summertime

[summertime]

But if You want, I would test Yog again to see, if after a sync the tables are 1:1. (not only the structure but also the field-data) and if it works on *our* tables & databases.

So when in table 1 one deletes a field and in table2 one appends a field or when user1 changes tel.No. of customer in table1 and another user changes street-address at the same customer or 3 different users change the same tel.no. of an customer ….

Yog must handle this, if it is a sync-prog and must sometimes ask the user, which transaction is the “right” one when there are conflicts – conflicts which cannot be resolved only by an program. If Yog can do that, its really a prog. that syncs “replicationlike” and this must be published very, very often – because that function is very seldom on the market.

As there are millions Excel-tables, dbase or xbase-tables on the market who need connection and/or converting to mySQL, there would be a great market for Yog.

Greetings summertime

[Shadow]

There are two separate tools to achieve that purpose. I'm sure SQLyog will further develop as time passes.

[Author]

Posts