Rick,

You are correct in saying (see thread for scope of variables) this is a "high level architecture discussion". Let me try to keep my question at that high level.

Programming for a website obviously has a very unique architecture in that data is not persistent across round trips between the users browser and the website server.

My website has what could be a unique requirement in that it pulls a lot of data from my foxpro database, time consuming in ANY environment. It will be necessary to reduce the instances of pulling that data so that website requests are fast.

My solution: Pull any data that is not session specific once, when the website server is started, storing that data in temporary cursors, properties and variables defined as global, where global means it is available to all website requests, for the life of the website server.

My question: Is my solution a realistic or "sound" method for reducing time consuming database access?

Thanks, John

Yes you can certainly cache data on startup and use it later, however I personally think this is very bad practice to load anything up front. It's much better to check at the point of use whether a resource exists (say a cursor), then create it and store it in a 'global' location. For values I would create and explicit global application object and store in on the Server object (like Server.Globals and Server.Globals.ItemCodeList). For cursors maybe prefix them with something like g_ so they're easily identifyable. Then check with IF !EMPTY() or !ISNULL() to check whehther the value exists before using it. Same with cursors and IF USED().

The key to efficient caching is consistency.

The reason I mention this is that things can and will go wrong. It's possible that some operations like admin operations will close all tables/cursors and whatever you had previously opened is no longer open. Assuming that things are always there is always a bad call hence I say check at point of use and if necessary delegate to helper functions to perform the load tasks required to keep the application code clean.

+++ Rick ---