[summertime]

@shadow

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

[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

[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]

we are testing a new hoster – crediblehost.com. With yog You cannot connect; with mySQLfront You cannot connect – even using php-Tunnel. But if You login – like described here – with user:password@…. then You can connect by php-Tunnel.

When I think about 50-60 very good programs on the market which connect to remote mySQL-database (otherwise they would be useless), than I suppose that there are 10.000 or 20.000 users who connect to mySQL from remote. Lets think only to the user of ODBC and we can say there are 100.000 users who connect by ODBC (or ADO ….) to remote mySQL-servers.

In many companies I know there is MS-Access as front-end and mySQL on a remote hoster; all connecting. So the security-argument (which is very often in political context too) is a fairy tale. As You point out, its very easy (but sometimes complicated for semi-skilled people) to reduce connection-rights to the individual customer.

The “localhost” is much more easier that listing ip-addresses, which are useless at dynamic IP's. For me it's not a security problem, it's a problem of willing to do a good work.

Even when You allow “%” in host, there are dozend of other restrictments to fulfill for “abusing” a system. And as the ODBC-commutity shows since more than 10 years – there are no security probs — if You have skilled people.

Regards summertime

[summertime]

I have them both — and I use them both. To 80% Yog and to 20% mySQLfront. If You have to one — You need the other, when You administrate very often.

Summertime

[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

[summertime]

@shadow

what kind of “security reasons”? (its often a fairy tale)

Most of the connetion problems are on the Yog-side (not on the remote server-side). proxy-connections including socks4/5 or tunneling is not a Yog-feature (yet).

[summertime]

@shadow

if yog would use e.g. the proxy, listed for example in InternetExplorer or firebird, etc. than many connections would work. You can learn that from myWitch.de or from Your competitor.

If yog would have socks4/socks5 features, many connections probs of yog would be in the past. With the sub-standard or standard-methods, many connection must fail.

regards summertime

[summertime]

@grendel

One aka *the* problem ist, that You cannot putin e.g. username:[email protected] or username:[email protected] — so the login with SQLyog fails. Possibly a feature that yog should have in future — like competive products.

regard summertime

[Author]

Posts