Dave, thanx for putting me straight. All I have to do now is confirm that this still holds under our particular db conditions....
>> Assuming you have declarative referential integrity - a defined relationship - no one should be able to delete records in one table if their deletion would create orphaned records in another table. ach! that's the problem. there's bugger all constraints and DRI within the db. this web app is a web version of a 4GL app that had it's referential integrity set in code, not the db. that's why all this guff about locking tables in the first place (althogh I take your point we're OTT in applying it) >> the point of DRI is to prevent applications from being able to screw up relations. yes, agreed - when the db has control over the DRI, that is... >> Performing a transaction within a stored procedure is equivalent to doing it with >> CFTRANSACTION, from the perspective of declarative referential integrity concerns. and if the db doesn't have DRI and has to rely on the app to enforce data integrity? >> Every query, within a larger transaction or just by itself, causes the database to lock records. In most cases, it's simply not necessary to do this yourself explicitly, since the database is doing it for you. ah ha! thanx for putting me straight. but further: "In most cases..." can you suggest any exceptions to this that I should look out for (keeping in mind the lack of db constraints we have)? Dave, I noticed (in a houseoffusion post) you shy away from try/catch within a transaction. how come? mate, thanx for your help cheers barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
