> 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)
Well, you can try to fix this by handling everything in your application and crossing your fingers, or you can redesign the database schema so that it's using referential integrity properly. I would recommend the latter, although admittedly that's easy for me to say and a bit harder for you to do. > and if the db doesn't have DRI and has to rely on the app to > enforce data integrity? You're screwed, then! Seriously, in that case it's up to you to ensure that you enforce relationships within your code, which basically means you'll need to build some mechanism to keep user A from colliding with user B. How you do this will be up to you, but it won't be too easy, I suspect. > 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)? Most of those cases are based on performance problems, I think, such as lock hotspots. > Dave, I noticed (in a houseoffusion post) you shy away from > try/catch within a transaction. how come? It's usually not necessary, especially within the commonly used example that is posted over and over again, in which an exception is thrown and caught within the CFTRANSACTION. If you have multiple queries using the same database connection within a CFTRANSACTION, and one of them fails, there's no need to catch that failure and issue a rollback, as the CFTRANSACTION tag will do that for you. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 ---------------------------------------------------------- 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]
