Never mind, I saw from the other posts that client vars are all
stored in the same entry. Well, at least my it goes to 11 statement
still stands...
-Erik
> -----Original Message-----
> From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> 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:[EMAIL PROTECTED]]
> > > > 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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
