>> I believe the original poster said that he could not change the database structure >> because it was a legacy app and "it worked".
aye, that is indeed the case (oh how I wish it was not so). Besides, there are (rare) areas where a user needs to access data across all companies (eg parts of financials). but something Nathan was pointing out about caching is worth touching on: is this caching of data or simply the filling properties of objects in shared scope? here's a simple example: an "occupation" object which stores vaild occupation types, complete with the usual CRUD methods as well as encapsulaing specific business logic for occupations. NOTE: each company would store it's own set of occ types (yes, I know: while an occ is simply an attribute of various entities, there is a business case to treat the concept of occ's as an object itself. this is just for an example - no OO arguments today please...) so either: 1) this is data - RAM-stored datasets (Nathan's point of building a caching API) and no data is stored in the occupation object's properties. or 2) these are properties - intrinsic to each object. Since the objects are stored in shared scope (SERVER), so are the values. which gets back to the initial subject: "to use or not to use - instance data" Nathan: did your gateway need to store any values itself (as object properties) or just called down into the cache every time? thanx barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
