You mentioned that each user gets their own database. No. Each user (in either of the schemes below) gets their own solitary record in a pair of database tables. Since CF creates the db tables for you there is no need for you to worry about such intricacies until you're ready to pick them apart.
There are a couple of different ways to do cvars in a db: 1. The Hard Way: Keep a separate client variable database for each application. You might want to do this if you want client variables for one site to expire after 10 days, and another to expiire after, say, 90. In actual practice I've found this to be overkill and after starting out this way I slowly rolled my cvars into... 2. The Simple Way: Set up a single datasource to handle all client variables across your entire server. Performance is not noticeably affected. Even if you are stuck with MS Access this is probably better for your server than using the Registry. I use a mySQL db to handle about 3 dozen sites and it's proven to be a fine solution over many months. You can expire client vars just like session vars, and can even dummy them up to handle complex structures ordinarily reserved for session vars. Hal Helms' site has a great step by step tutorial on this topic (http://www.halhelms.com). Personally I prefer their stability and scalability over session vars by a mile. --Matt Robertson-- MSB Designs, Inc. http://mysecretbase.com -----Original Message----- From: FlashGuy [mailto:flashmx@;rogers.com] Sent: Wednesday, October 16, 2002 1:38 PM To: CF-Talk Subject: Re: Session variables So are you saying that for every user that logs into the interface to have a separate database to store the client variables for each user? There could be 50-100 users. On Wed, 16 Oct 2002 15:11:51 -0400, S. Isaac Dealey wrote: > >> Session variables expire according to a timer from the last request > >> (configurable > >> via the administrator). You can set a very long time-out, and then use > >> one of > >> the available custom tags to blow the variables away on log-out, but > >> there is > >> still no way to know that the user has closed the browser. Still, this > >> may be > >> acceptable so long as you understand that the persistent session > >> variables > >> are taking up space in the CF server's memory, which may be problem if > >> you have lots of sessions and may not if you don't. > > > There could be 50-100 session open at the same time. Possibly accessing > > the same data/directories etc. > > I would probably go with client variables stored in an enterprise database ( > MS SQL 2000 or Oracle -- !NOT! the same DB the application is using ). Use > <cfcookie> to re-set the cfid and cftoken cookies to expire when the browser > closes, and disable global client variable updates in your client variables > storage db. This should tame usage of RAM on the server and by storing the > client variables in a separate db and disabling global client variable > updates you'll reduce the amount of db access for client variables and > mitigate the risks of db conflicts with client variables... > > I noticed here that when I tried to reference a client variable directly > from within a stored procedure call and the client variables were stored in > the same db, the cf server threw an unknown exception condition and > restarted itself immediately. Took several hours to figure out what was > wrong. That's why I say it's really important that you not store your client > variables in the same db. But then you also want to make sure you don't > store them in the registry to prevent possible registry corruption, etc. > Storing them in cookies is just less secure -- lets people who know how to > edit cookies have at them. > > S. Isaac Dealey > Certified Advanced ColdFusion 5 Developer > > www.turnkey.to > 954-776-0046 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
