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
