i guess in all the 3 cases(registry, DB, cookies) there were would be 2
client cookies set (CFID, CFTOKEN) once we set "setclientcookies=yes" in our
application.cfm.
akbar
-Original Message-
From: Bill Killillay [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 17, 2000 7:16 PM
To: CF-Ta
Bud,
If you went through all of this trouble already, why not just get rid
of all session / client / application variables all together. I don't
really see the need for them. You can create your own database, and your
own clientID and password, and pass them along to each form This way
At 08:46 AM 8/19/00 -0400, you wrote:
>Well. Due to my utter confusion over cflocks,
Thanks! I thot I was the only one ;-)
Does the following mean you let the database take care of locking
client variables and you don't bother CF with this little detail?
best, paul
> I've gone in to my
>shop
1. It's better to create a seperate database because the cfid and cftoken
have to be unique. You dont have to fight with other applications it's just
easier to manage one database of client variables then it would to have 10.
2. Since they are being written to a database there shouldn't be a prob
On 8/19/00, Al Musella, DPM penned:
>If you went through all of this trouble already, why not just get rid
>of all session / client / application variables all together. I don't
>really see the need for them. You can create your own database, and your
>own clientID and password, and pass them alo
On 8/19/00, paul smith penned:
>Does the following mean you let the database take care of locking
>client variables and you don't bother CF with this little detail?
Client variables are written to a database or the registry and
therefore are not susceptible to problems caused by multiple users
So as far as variables go (putting aside CFFILE considerations, and some
others mentioned by Forta such as CFX tags that aren't multithread safe and
CFHTTP) -- AND IF I have only:
APPLICATION scoped variables that once set are read only
VARIABLES scoped variables, and
CLIENT scoped variables
a
On 8/19/00, paul smith penned:
>APPLICATION scoped variables that once set are read only
>VARIABLES scoped variables, and
>CLIENT scoped variables
>
>and no other non-scoped variables,
>
>then I don't have to worry about CF locking.
I believe the general consensus is you should still lock the
ap
Did you have ColdFusion create the tables on your production server when
switching to ODBC client storage, or did you import them from the dev box?
If you didn't have CF create the tables, it's possible you selected an
incorrect datatype.
Joseph DeVore
VeloxWeb Technologies
-Original Mes
> Our main web server has a registry that is huge because of
> the CF client storage. So, I decide to store client data in
> a SQL db. I can get this to work fine on my development server
> but when I try to do the same thing for the production server
> I get a SQL error when accessing pages:
I had CF create them.
Howie
- Original Message -
From: "Joseph DeVore" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 5:41 PM
Subject: RE: Client storage woes
> Did you have ColdFusion create the tables on your
- Original Message -
From: "Dave Watts" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 5:50 PM
Subject: RE: Client storage woes
> > Our main web server has a registry that is huge because of
> > t
My production server has 2.5.1 and the dev server has 2.6. Would you recommend
upgrading to 2.6 or 2.7?
Thanks,
Howie
- Original Message -
From: "Dave Watts" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 5:5
> My production server has 2.5.1 and the dev server has 2.6.
> Would you recommend upgrading to 2.6 or 2.7?
I didn't even know there was a 2.7, so I'm probably not qualified to give
you advice on this. I'd probably stick with 2.6 SP1, since you know that
works on the dev server.
Dave Watts, CT
Compare the field types in your SQL Server databases on Dev and Production.
Your production database field type may need modified.
Tony Gruen
sfnetworks
-Original Message-
From: Howie Hamlin [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 18, 2001 1:54 PM
To: CF-Talk
Subject: Client st
They are the same. I had CF create the tables...
Thanks,
Howie
- Original Message -
From: "Tony Gruen" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 7:26 PM
Subject: RE: Client storage woes
> Compare
signs, Inc. http://mysecretbase.com
-
- Original Message -
From: "Howie Hamlin" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 5:53 PM
Subject: Re: Client storage woes
They are
I haven't tried that yet but it's worth a shot.
Regards,
Howie
- Original Message -
From: "Matt Robertson" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 10:23 PM
Subject: Re: Client storage woes
>
Well, the reboot actually worked - thanks for the suggestion.
Regards,
Howie
- Original Message -
From: "Matt Robertson" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 10:23 PM
Subject: Re: Client storage woes
&
Cool. Get some sleep ;D
Cheers,
--Matt--
- Original Message -
From: "Howie Hamlin" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 12:22 AM
Subject: Re: Client storage woes
Well, the reboot actually worked - tha
Ha - as soon as I get home :-)
Luckily, the office is only a mile from home...
Regards,
Howie
- Original Message -
From: "Matt Robertson" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 3:35 AM
Subject: Re: Client
On 11/18/01, Howie Hamlin penned:
> > 1. Is the data schema exactly the same for both development and production
>> databases for the CDATA and CGLOBAL tables? Unless you created the data
>> schema manually, this shouldn't be a problem.
>>
>
>I had CF create the tables.
Maybe CF screwed up som
token caused the errorstrange...
Howie
- Original Message -
From: "Bud" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 8:27 AM
Subject: Re: Client storage woes
> On 11/18/01, Howie Hamlin penned:
> > >
I suspect its been fixed in MX, what with the improved support for mySQL and all.
However the root cause of the problem was mySQL's failure to support subqueries, so
this may not be the case.
I CFSCHEDULE the template below, which I got way back when from the Allaire KB. Works
like a charm.
> Howdy all. Any pros/cons on way or the other about where to store
> client variables?
The registry is not a good place to store Client variables, which are
relatively volatile data. The registry is designed for storing data that
will be read often, but written infrequently. If you use more spac
TECTED]
Subject: RE: Client Storage: registry or database
> Howdy all. Any pros/cons on way or the other about where to store
> client variables?
The registry is not a good place to store Client variables, which are
relatively volatile data. The registry is designed for storing data that
wi
AIL PROTECTED]]
> Sent: Saturday, April 01, 2000 6:28 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Client Storage: registry or database
>
>
> On that same topic, I wanted to add that if you choose to store
> those variables in a database, then you would be able to share
> those variable
> -Original Message-
> From: Cameron Childress [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, April 01, 2000 5:11 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Client Storage: registry or database
>
> > however as I understand you can't rely upon client v
You can configure client variable storage ONLY at the CF server instance
level. However, it's amazingly trivial to create your own client variables
storage mechanims, which can store stuff wherever you want. And since
you're storing everything yourself, you can extend the functionality as
well, s
You can do one Client DB for 10 Applications with different application
names
Or
One Client DB per Application
However i would recommend using a SQL Server Scheduled Jobs to Purge Client
data.
Joe
- Original Message -
From: "Tangorre, Michael" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL P
> If I have 10 applications one one server and 10 DBs on one
> sql server, is it possible to have each application handle
> its own client variable tables?
Yes. You'll have to configure each datasource to store Client variables
within the CF Administrator, and you'll have to specify a CLIENTSTOR
CF-Talk
> Subject: RE: Client Storage in DB Per Application
>
> > If I have 10 applications one one server and 10 DBs on one
> > sql server, is it possible to have each application handle
> > its own client variable tables?
>
> Yes. You'll have to configure eac
Yes. You can set up each of the datasources as an acceptable client
variable repository in the cfadmin (what Barney said), then point to
that repository using the clientstorage parameter in your
Application.cfm's cfapplication statement.
Since my cms uses client vars extensively, I used to get th
Thanks everyone. I am all set now. That was easy... :-)
Mike
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
[Donations and Support]
This has nothing to do with client variables. Cold Fusion uses the Registry
a great deal itself internally. For example, all datasource info, scheduled
tasks, etc...
--
Archives: http://www.mail-archive.com/cf-talk@house
9:09
To: [EMAIL PROTECTED]
Subject: RE: Client storage (RE: ColdFusion 4.0.1/SPARC/Solaris help
sought - registry corruption and cf scheduler problems)
This has nothing to do with client variables. Cold Fusion uses the Registry
a great deal itself internally. For example, all datasource i
Well, yeah, using client variables in the registry certainly won't help, but
the point is that the registry on Solaris is fubar (we won't get into NT.)
I'm not saying everyone should start refreshing their registry every day...
I'm saying that it's not difficult at all to find yourself with a very
eldon
http://www.desertraven.com/
Make a fast friend, adopt a greyhound!
-Original Message-
From: Ed Toon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 22:09
To: [EMAIL PROTECTED]
Subject: RE: Client storage (RE: ColdFusion 4.0.1/SPARC/Solaris help
sought - registry corrupt
> If you're using client vars, get them into a database. If
> you're not using them, make absolutely sure they're not enabled
> anywhere.
I'd like to strongly second this recommendation. No one, under any
circumstances, should store client variables for an application within the
registry. The
> This has nothing to do with client variables. Cold Fusion
> uses the Registry a great deal itself internally. For example,
> all datasource info, scheduled tasks, etc...
Most of this is done when the service starts up, and reads the data from the
Registry.
The Registry isn't designed to stor
40 matches
Mail list logo