-Erik

> -----Original Message----- > From: Erik Voldengen [mailto:erikv@erikv.com] > Sent: Tuesday, April 17, 2001 10:29 PM > To: Fusebox > Subject: RE: using client vars to maintain session state > > > uhhhhhhhhhh, yeah, but this one goes to 11. > > 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