actually I might use the APPLICATION scope to handle this...
When someone opens a record for editing set the following variable:
<cfset "application.record#recordID#" = now()>
When the person commits changes to the DB delete it from the struct like so:
<cfset foo = StructDelete(application, "record#recordID#")>
Then when someone else tries to open it you can check to see if it exists in
the application struct and how long it's been there:
<cfif StructKeyExists(application, "record#recordID#")>
<cfif dateDiff("n",evaluate("application.record#recordID#"), now())
LT maxAllowedLockTime>
<b>Forget it!<b>
<cfabort>
<cfelse>
<!-- it shouldn't be there - max allowed lock time
exceeded... -->
[...delete from struct...]
</cfif>
</cfif>
where "maxAllowedLockTime" is some variable you set in minutes for how long
a person can keep a record locked before timeout.
Anyway, you get the idea...
+-----------------------------------------------+
Bryan Love
Macromedia Certified Professional
Internet Application Developer
Database Analyst
Telecommunication Systems
[EMAIL PROTECTED]
+-----------------------------------------------+
"...'If there must be trouble, let it be in my day, that my child may have
peace'..."
- Thomas Paine, The American Crisis
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 2:37 PM
To: CF-Talk
Subject: RE: Locking a record in database!!
> Can any one tell me how to lock a record in the table
> for some time.
>
> When One record is opened for writing through a form, I
> don't anyone else to open that particular record. I don't
> know at which level this should be done either at Database
> level or in ColdFusion.
The short answer is, you can't, and you really don't want to be able to do
that anyway for various reasons. The problem you're trying to solve is a
concurrency problem, but it doesn't lend itself well to a locking solution.
Instead, you might use a simple timestamp solution - add a field to the
record to track when it was last changed, and check the field's value before
allowing a user's changes to be accepted. If the value is different than it
was when the user first selected the record for editing, you know it's been
changed since then, and you can address that various ways in code.
In most CF applications I've seen, the developers have simply ignored
concurrency issues with multiple editors, which isn't really a good idea,
but locking the database to prevent it would be even worse, since there's no
"persistent connection" between the browser and the database. However,
implementing the timestamp model described above is pretty trivial - I've
done it in fifteen minutes or less in classrooms for student demonstrations.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
______________________________________________________________________
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
