[Erik]

The problem resolved itself: The ISP upgraded to 4.1.7 😉

[Erik]

I hope you can help me with this timestamp problem?

I really want to get the client-server setup ready in November.

[Erik]

Maybe you can add a timestamp / date column in your source DB and construct a XML script with a sqlwhere tag like :

Code:

date = CURDATE()

or something similar. This will only get the rows with date = today. You'll just have to run the script daily 😉

Hth

[Erik]

1 member is celebrating his/her birthday today

>Ritesh (21)

🙂

[Erik]

Ritesh wrote on Nov 25 2004, 11:39 AM:

Are you still facing problems in the 'live' setup (client = 4.1.7, server = 4.0.21) with the latest release?

Yes – with the timestamps definition mismatch.

[edit] Congratulations BTW 😉 [/edit]

[Erik]

Ok I'll try 🙂

I've got two setups – one at home for development, and one 'live' setup at my customer's office.

At home I had a unix/freebsd server with mysql 3.23 and a windows client with mysql 3.23. Everything worked fine with no problems at all. When I tried the exact same db structures for client and server at my customer's office (client = 3.23 and server = 4.0.21) synchronising didn't work. I got a lot of errors like:

Code:

Error No. 1062
Duplicate entry '2' for key 1
Error No. 1062
Duplicate entry '1012' for key 1

I figured it had something to do with the versions because that was the only difference between development and live setup. I upgraded the development setup to 4.1.7 (which implies upgrading to the new sqlyog which we did). Everything works fine again in there (client = 4.1.7, server = 4.1.7) – but not in the 'live' setup (client = 4.1.7, server = 4.0.21).

I can't do anything about 4.0.21 – it's running at an ISP.

The odd thing about this is I'm not even synchronising this timestamp column! It's just workaround for MS Access at the client machines.

That's about the whole story (-:

Maybe using one of the alternative synchronising methods (http or ssh tunnel) is a solution to avoid this problem?

[Author]

Posts