On Mon, May 21, 2012 at 12:31 PM, MB Software Solutions, LLC <[email protected]> wrote: > On 5/21/2012 1:29 PM, Kevin Cully wrote: >> In addition to what Frank and Michael said, you may want to have table >> that just stores when the lookup table was last updated. When the app >> detects that the value changed, then they know that combobox needs to be >> refreshed with new/updated data. >> >> Lets say you have a combobox listing the donut types available in the >> shop, we get the last updated date: >> select TimeOfLastUpdate from {StatusTable} where cSetting='donut'; >> >> If ever the above query changes the value of TimeOfLastUpdate, then you >> know you have to query the {DonutsAvailable} table for the goal of less >> data transfer. > > > Many times I wonder about storing a copy of lookup tables locally and > using some sync method (since it's a 1-way sync...the server is always > the master/right version) and checking such a "last update" kind of > field and updating where necessary. Would make for quicker lookups of > course. Not sure of the maintenance headache that might create? Surely > more working/moving parts means more possible chance of problems. Right? ------------------
Aren't they always a cursor? -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAJidMYLJ6FNu_tOffpT=92aejpbsothdr1ciyst0uj2f4sq...@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.
