Re: Best way to do one-way synchronized approach?
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 - 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...@mbsoftwaresolutions.com a écrit : 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. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/291e9bfe238b579b038fe9b4b2c5d...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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...@mbsoftwaresolutions.com a écrit : 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. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/55b23a43.8080...@foxincloud.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 the idea. Oooothis looks like a great ideathanks!! ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/e507ec52ea6b88baefb9c3b48e9f1...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Why not check the directory date stamp for last modified? This is not perfect as someone could modify the file and then reset the last-modified datestamp (but that is stretching), or could somehow change the last-modified datestamp without changing the file (which would result in unneeded copies). Sincerely, Gene Wirchenko ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/ ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 course, is (stop me if you have heard this before!) testing it on your hardware with your application or your network under a typical network traffic load. On Fri, Jul 17, 2015 at 2:03 PM, Kevin Cully kcu...@cullytechnologies.com 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 value to lookup.md5 During the startup of the application, compare the local lookup.md5 with the file on the server. Should really be quick to execute. CULLY Technologies, LLC http://cullytechnologies.com http://cully.biz On 07/17/2015 12:01 PM, 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---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4smsdmv4b2nhgop+cwurqcjjkle05j6hdonml+befm...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 to pull them locally for faster processing---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Why not check the directory date stamp for last modified? This is not perfect as someone could modify the file and then reset the last-modified datestamp (but that is stretching), or could somehow change the last-modified datestamp without changing the file (which would result in unneeded copies). The source table is a MySQL table on the server, so file timestamp does not apply. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/01f5e16e1f5ab90f7bbefa1e92d9f...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 value to lookup.md5 During the startup of the application, compare the local lookup.md5 with the file on the server. Should really be quick to execute. CULLY Technologies, LLC http://cullytechnologies.com http://cully.biz On 07/17/2015 12:01 PM, 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---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/674367701e4fecc54a06f40cc5cf7...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 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 course, is (stop me if you have heard this before!) testing it on your hardware with your application or your network under a typical network traffic load. On Fri, Jul 17, 2015 at 2:03 PM, Kevin Cully kcu...@cullytechnologies.com 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 value to lookup.md5 During the startup of the application, compare the local lookup.md5 with the file on the server. Should really be quick to execute. CULLY Technologies, LLC http://cullytechnologies.com http://cully.biz On 07/17/2015 12:01 PM, 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---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/3cb51f9b19a4cbaa2f507c4901a67...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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://cullytechnologies.com http://cully.biz On 07/17/2015 03:20 PM, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: 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. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/55a95615.4000...@cullytechnologies.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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. Should really be quick to execute. CULLY Technologies, LLC http://cullytechnologies.com http://cully.biz On 07/17/2015 12:01 PM, 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---BUT I DON'T WANT TO PULL THEM EVERY TIME WHEN NOTHING HAS CHANGED. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/55a9435e.6060...@cullytechnologies.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 class has been instanciated and the table downloaded. When you need the table in another datasession, you use the clause NOREQUERY 1 of the command USE : NOREQUERY [nDataSessionNumber] Specifies that data from a remote SQL view is not downloaded again. NOREQUERY is available only for SQL views and is typically used when you open a SQL view again by including the AGAIN clause. Including the NOREQUERY clause increases performance for large data sets because the data does not need to be downloaded again. nDataSessionNumber can be included to specify that data for a remote SQL view in a specific data session isn't downloaded again. If nDataSessionNumber is omitted, data isn't downloaded for the view open in the current data session. HTH The Foxil --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/55a96259.30...@wanadoo.fr ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Best way to do one-way synchronized approach?
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 18:01 GMT+02:00 mbsoftwaresoluti...@mbsoftwaresolutions.com: 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. What's the best way to achieve this, trying to only update locally when something has changed on the server table? I was initially thinking looking at the CHECKSUM on the server table, keeping that locally in some sort of lookup table of its own, and only updating the local table when that checksum value is different. Now I don't want to get as granular (yet) as a row-by-row comparison, since these tables (maybe 10) will most likely have no more than a few thousand rows. Ideas? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cagq_junrm9lyr0xbcxvm+g_knwaqfrw_d0hvnbzw5zgxmrd...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
