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
<[email protected]> 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, [email protected] 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: [email protected]
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.

Reply via email to