Re: Best way to do one-way synchronized approach?

2015-07-24 Thread mbsoftwaresolutions
Hi Thierry, The source is a MySQL table on a server, not a VFP table. But thanks for the tip! --Mike On 2015-07-24 09:14, Thierry Nivelet wrote: Mike, FoxInCloud comes with a 2-way VFP data sync class, at table or DBC level, in production for over 6 years, relying on : - PKs or CKs - times

Re: Best way to do one-way synchronized approach?

2015-07-24 Thread Thierry Nivelet
Mike, FoxInCloud comes with a 2-way VFP data sync class, at table or DBC level, in production for over 6 years, relying on : - PKs or CKs - timestamp field Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/ Le 17/07/2015 18:01, mbsoftwaresoluti...@m

Re: Best way to do one-way synchronized approach?

2015-07-23 Thread mbsoftwaresolutions
On 2015-07-17 15:23, Kevin Cully wrote: Create a trigger on the insert or update for the lookup table into a checksum table. The trigger could UPDATE CheckSumTable SET TableUUID=UUID(), LastUpdate=NOW() WHERE TRIM(TableName)='LookupTable'; The above code needs to be MariaDB-SQLized but you get

Re: (Re-sending) Best way to do one-way synchronized approach?

2015-07-18 Thread mbsoftwaresolutions
On 2015-07-18 04:24, Laurie Alvey wrote: Have you tried comparing LUPDATE() on the server and the local tables? It's a MySQL table on the server, so LUPDATE is not an option. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://ma

Re: (Re-sending) Best way to do one-way synchronized approach?

2015-07-18 Thread Laurie Alvey
Have you tried comparing LUPDATE() on the server and the local tables? Laurie On 17 July 2015 at 20:16, wrote: > Ken Dibble -- I never saw my original show up either. Let's try this > again. > > > Say I've got tables on a server that are "lookup" libraries, and by that, > I mean the change som

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Fernando D. Bozzo
Hi Mike: You may use the same approach that is recommended when using remote views to SQL-Server or other Databases to sync in local, that is using a timestamp field which is used in conjunction with the primary key for quickly obtain the new records, and update your local tables. 2015-07-17

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Jean MAURICE
there is another solution not so efficient that the one you want but a lot more simpler. The first time a table is needed for lookup, you download it in the datasession n°1 (for example). I do this using a class with a child class for each table. Using pemstatus( ,5) I can chek if the child cl

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Kevin Cully
Create a trigger on the insert or update for the lookup table into a checksum table. The trigger could UPDATE CheckSumTable SET TableUUID=UUID(), LastUpdate=NOW() WHERE TRIM(TableName)='LookupTable'; The above code needs to be MariaDB-SQLized but you get the idea. CULLY Technologies, LLC http

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread mbsoftwaresolutions
Sorry...I should have specified: this is NOT a VFP table on the server, but MySQL instead. The local copy would be a Fox table though. On 2015-07-17 15:08, Ted Roche wrote: You can check LUPDATE() on the remote tables. Or create a master table on the server that stores the datetime the tables

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread mbsoftwaresolutions
Hi Kevin! That's what I meant by my CHECKSUM checking comment. Thanks, --Mike On 2015-07-17 14:03, Kevin Cully wrote: I'd probably do an MD5 on the lookup table and save that to a text file. Then compare that to a local file. Example: lookup.dbf ... do an MD5 on lookup.dbf and save that val

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread mbsoftwaresolutions
On 2015-07-17 13:24, Gene Wirchenko wrote: At 09:01 2015-07-17, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: Say I've got tables on a server that are "lookup" libraries, and by that, I mean the change somewhat infrequently. Instead of always searching those tables on the server, I'd like

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Ted Roche
You can check LUPDATE() on the remote tables. Or create a master table on the server that stores the datetime the tables were last updated. Frankly with current network speeds, disk and RAM caching, I'd be skeptical whether all this overhead would be justified. The only way to be certain, of cours

(Re-sending) Best way to do one-way synchronized approach?

2015-07-17 Thread mbsoftwaresolutions
Ken Dibble -- I never saw my original show up either. Let's try this again. Say I've got tables on a server that are "lookup" libraries, and by that, I mean the change somewhat infrequently. Instead of always searching those tables on the server, I'd like to pull them locally for faster pr

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Kevin Cully
I'd probably do an MD5 on the lookup table and save that to a text file. Then compare that to a local file. Example: lookup.dbf ... do an MD5 on lookup.dbf and save that value to lookup.md5 During the startup of the application, compare the local lookup.md5 with the file on the server. Shoul

Re: Best way to do one-way synchronized approach?

2015-07-17 Thread Gene Wirchenko
At 09:01 2015-07-17, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: Say I've got tables on a server that are "lookup" libraries, and by that, I mean the change somewhat infrequently. Instead of always searching those tables on the server, I'd like to pull them locally for faster processing

Best way to do one-way synchronized approach?

2015-07-17 Thread mbsoftwaresolutions
Say I've got tables on a server that are "lookup" libraries, and by that, I mean the change somewhat infrequently. Instead of always searching those tables on the server, I'd like to pull them locally for faster processing---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. W