Writing to a file

[Cold_Fish]

hi everyone,

I have a file that only contains a number in it (invoice number).  Every time someone submits a form, it should increase the value of the number in the file by one. 

It's my understanding that the file should be "locked" while it is being written to, so it does not give a duplicate amount if two people submit at the same time.  Upon updating the file, it would then unlock the file, so it could then be written to by the next transaction.

The file would exist in the same folder as the form. 

That's just my speculation as to how I think it should work. Basically, Open file, Lock file, write to file, unlock file.

Does anyone know of any tutorials that would show how to do this?

Thanks!

[BKBK · Accepted solution]

<cfset fileName = expandPath("counter.txt")>

<cflock name="fileReadLock" type="exclusive" timeout="20" throwontimeout="yes">

<cfif fileExists(fileName)>

    <cffile action="read" file="#fileName#" variable="fileContent">

    <cfif not isNumeric(fileContent)>

        <cfthrow message="Content of file counter.txt is non-numerical.">

        <cfabort>

    </cfif>

    <cfset fileContent = fileContent+1>

    <cffile action="write" file="#expandpath('counter.txt')#" output="#fileContent#">

<cfelse>

    <cfthrow message="Counting file counter.txt is in the wrong location or does not exist.">

    <cfabort>

</cfif>

Current count: <cfoutput>#fileContent#</cfoutput>

</cflock>

[Cold_Fish]

BKBK!!!

That was exactly what I needed!  I implemented it into my current code and it worked perfectly!  Thank-you so much for your help with this!  It is very much appreciated!

Graham.

[Dave Ferguson]

While BKBK does give you a way that it will work I am wondering why you would even do this?  This has more ways it could fail than I can count.  Among them, you could easily have a lock left behind on the file thus making it unreadable.  You should really be storing this data in a database not a file.

--Dave

[Scott Stroz]

This is an incredibly bad way to manage this information - so bad it cannot be measured with existing technology.

Store the number in a DB, not in a file to be read/written to frequently. Too many factors that can cause this to go belly up.

[Cold_Fish]

Thank-you for your concerns.

I am open to other methods to accomplish the same thing, but need a little more help than simply "write it to a database".  I would likely need use MSAccess as the database for this counter if I'm going to go this method.

I'm willing to learn!

Graham.

[Dave Ferguson]

Your application doesn't use a database at all?  I find that a little strange and at the same time Interesting.  First, don't use MS Access for well, anything.  If you don't have a DB use something like Mysql.  It is free and works very well.

[BKBK]

Circumstances may justify file storage (though, as you later revealed, that doesn't apply to you). Think, for example, of the absence of a database connection or of a database with a lock and excessive traffic. File storage even has pride of place in certain areas. Most applications in fact store configuration information on the file system, which they then update throughout the working life of the application.

Having said that, I should hasten to add that I agree with the other posters: a database is preferable to a file for this kind of storage. However, I would be less negative in my appraisal of file storage in general. At least, not until I know the circumstances.

I would choose MySQL. If for whatever reason you have to use MS Access - I have heard about a System Admin who imposed it on his Developer colleagues - then do so by all means. It will still be a step in the right direction.