Excellent! Thanks for taking the time to address this in such a thorough
and practical manner. "INI" just might be the little hidden jewel I was
looking for.
Since we need portability, your input suggests that we should develop
multiple options. Selectable at installation. In this order 1. CFFILE, 2.
INI and 3. server variables.
Nick
At 01:27 PM 10/11/2003 -0400, you wrote:
>When you say "temporary" how temporary do you mean? The big difference
>here is that a file is permanent (will survive a server reboot) while
>server (or application) variables will not. So if you want your data to
>be persistent past a reboot/recycle then you'll need some sort of file
>storage.
>
>
>Unfortunately many hosts disable CFFILE. Another option you might
>consider is CFs built in support for standard "INI" formatted files. I
>actually find this much easy to use that CFFILE (at least for storing
>small values) in any case.
>
>
>We set up an INI file with all of our application options and, upon
>initialization, read all those values into the Application scope. Works
>a treat.
>
>
>Server variables are another option (if you can deal with the
>non-persistent nature of them). They can be a problem on CF 5 or below
>(due to server instability from lack of locking) but not on MX. If the
>values use are both small and lightly used (quick in'n'out) then it
>should be fine. In the past I've created server structure based on the
>domain name plus a "PIN" number to help ensure that the names are
>unique. For example if the domain was mysite.com and I selected "1234"
>as my pin I might create a struct named "server.ComMySite_1234" to hold
>all the variables.
>
>
>This way it's VERY unlikely that somebody will overwrite them (by
>accident). However anybody on the server can dump the server scope and
>overwrite them on purpose (or see/modify the values in there just to
>mess with you). In general on a shared box it's highly recommended not
>to use the server scope.
>
>
>All told I would try out the INI file first (using CFs
>GetProfileString() and SetProfileString() functions). I believe that
>hosts can disable these as well - but it's much, much less likely
>(although it's very likely that they will only let you access files in
>your own space).
>
>
>Jim Davis
>
>-----Original Message-----
>From: Nick Baker [mailto:[EMAIL PROTECTED]
>Sent: Saturday, October 11, 2003 1:53 AM
>To: CF-Talk
>Subject: Temporary Storage Options
>
>
>CF 4.5 and Up
>
>I am developing a CF package that needs to be compatible with most CF
>Hosting services. I want to cover all bases and make sure I am not
>missing
>something.
>
>We need temporary storage for a small set of data. This data will be
>updated with each site visitor, older data will be deleted after 48 or
>sooner if the size exceeds a few Kbytes. It is preferable not to include
>
>this info in our existing DBs, or add the extra overhead of additional
>DB.
>
>Are there methods beyond
>
>1. Server Variables?
>2. A text file via CFFile?
>
>Thanks,
>
>Nick
>
> _____
>
>
>----------
>[
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
