That's a good point. It just seemed to me that one variable in the db was better than 20. Does anyone know if CF creates a new entry in the DB for every Client variable, or are they combined into one in some manner?

If each client variable requires a new db entry, it definately would cut down on the number of entries in your DB (for storing Client variables), that's for sure. And like you, I was worried about setting so many client variables. I put the deserialization in an app_ file, and if therefore had the hacked cf query available whenever I needed it.

-Erik

> > Thanks Erik, > > What is the difference in doing this as opposed to allowing > CF to maintain > the client state. Doesn't it essentially do the same thing by > writing the > data to the DB. I guess it doesn't serialize it, does the > serialization > make that big a difference? I thought that client vars with > db storage > turned on, created a package out of the data anyways? > > I think I'm missing your point a bit. > > Brook > > At 01:40 PM 17/04/01 -0700, you wrote: > >I was worried about this very topic about 9 months ago when > >we began a huge project. Each client was going to need several > >client variables to accomplish what I wanted. > > > >The solution was to make a query, serialize it to a wddx packet, > >and set it to a single client variable. It works very well. > > > >You can run an initial query for the user, get a bunch of info, > >and add to that query doing something like this (warning, put > >on your hack goggles): > > > ><CFSET TempArray = ArrayNew(1)> > ><CFSET TempArray[1] = "#ValueList(GetSubscriptions.SubscriptionID)#"> > ><CFSET temp = QueryAddColumn(getLogin, > >"#GetSubscriptionTypes.TableName#_Subscriptions", TempArray)> > > > >I did this because it was almost impossible to write a > dynamic query that > >contained all the data I needed. Plus, it was hitting three > different > >databases, which does not make things easy. > > > >When you've added all you want to the query, just serialize it: > > > ><CFWDDX ACTION='cfml2wddx' input=#GetLogin# > output='Client.MemberInfo'> > > > >It works like a champ. > > > >-Erik Voldengen > > > > > > > -----Original Message----- > > > From: Brook Davies [mailto:brook@maracasmedia.com] > > > Sent: Tuesday, April 17, 2001 12:23 PM > > > To: Fusebox > > > Subject: using client vars to maintain session state > > > > > > > > > Hi, > > > > > > What I want to know if how much is too much when it comes to > > > client vars > > > with DB storage. If each client has 40 variables that are be > > > written to the > > > db on ever request, will these slow things down considerably? > > > What about > > > large client vars containing say 35-45k text. Is this the end > > > of the world? > > > > > > What do you guys think? > > > > > > sqlserver 7.0 (dual 550, 1gig ram) > > > IIs nt4.0, CF4.5.1, dual 550, 756 ram) > > > > > > Brook Davies > > > Maracasmedia Inc > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/fusebox@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists