- This topic is empty.
-
AuthorPosts
-
-
August 12, 2005 at 6:31 pm #9163macrailMember
I have registered today for SQLyog as I need to synch 5 laptop users with the web based mysql database.
The synchronization in sqlyog is brilliant and I soon got the thing working to my satisfaction, but then disaster struck! I did not consider what would happen if two users synch'ed data they had entered offline with the server. As the tables concerned are PK auto increment it meant that the server would over write the losers data.
To overcome this I decided to use a timestamp inserted by our webpage at the precise time the user clicks the insert button. This is fine but what will happen when clocks go forward/back is I may get duplicate values. What I want to do is to store a primary key that is made up of a timestamp and some other unique numerical/text data.
My question is therefore:- Is there a way to join the timestamp value with text and numeric data at insert time via php?
I am looking for the same sort of functionality as say MS Access replication GUID's to ensure that my operation is scalable for the future.
Thanks (and apologies for the length),
Ian
-
August 13, 2005 at 8:07 am #18906peterlaursenParticipantQUOTEMy question is therefore:- Is there a way to join the timestamp value with text and numeric data at insert time via php?
there is absolutely no correlation between SQLyog an the scripting language php. But a PK can be built from several fields – just coneect to the database(s) with SQLyog and select the fields that you want to use for the PK from ALTER TABLE functionality.
Myabe you can use something form this article
http://www.webyog.com/forums/index.php?showtopic=1507
there is a simple trick desribed here
QUOTEIf you want to be 100% sure that you don’t lose newly created data with the sync and also want to ensure that all data is synced you can build a PK composed of any field(s) that you would normally for a PK AND any other having different DEFAULT value on the two hosts. It doesn’t matter if that variable is a number-type and has defaults for instance “0†and “1†respectively or it’s a char-type having defaults for instance “webhost†and “localhostâ€. With this new PK “conflicting primary keys†will not occur during sync, since the same value for the PK would never exist on both hosts with data created since last sync. The host-specific part of such PK will always tell on which host the row was first created
-
-
AuthorPosts
- You must be logged in to reply to this topic.