Thanks for the thought, Peter > ... but it really made me think > :) > > What are the stored procs doing?
First one does an insert, throws back an id, which is then used to do another set of inserts, using that returned id only. It had always been my impression with CF that the use of <cftransaction> was to ensure that either both of the sps (in this case) go to conclusion, or neither. There does not seem to be any possiblity of the wrong id being used in the second sp. A named lock would make sense, though. > > Also, if you're using any kind of source code control, take a look > historically at the code to see if the reasons for the locks were > removed recently. :S > > - Peter No source code control changes - I saw this 'problem' back in August last year, and it has not yet been rectified. This app apparently has data lock issues, and I'm trying to eliminate possible causes. Cheers Terry > > -----Original Message----- > From: Mark Woods [mailto:[EMAIL PROTECTED] > Sent: 08 April 2004 14:27 > To: [EMAIL PROTECTED] > Subject: Re: [ cf-dev ] Locking > > > > >If neither of the queries utilises or sets a session variable, can > anyone > >see any reason to have the queries within a readonly session cflock, > >within the <cftransaction> block? > > nope > -- These lists are syncronised with the CFDeveloper forum at http://forum.cfdeveloper.co.uk/ Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ CFDeveloper Sponsors and contributors:- *Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF provided by activepdf.com* *Forums provided by fusetalk.com* :: *ProWorkFlow provided by proworkflow.com* *Tutorials provided by helmguru.com* :: *Lists hosted by gradwell.com* To unsubscribe, e-mail: [EMAIL PROTECTED]
