I'm not saying don't use the key. I'm saying you can catch 99.9% (if not 100%) of the issues with an explicit check at the same time as all your other validation errors, rather than having to do your validation, maybe reprompt the user, and then once it's valid, do an INSERT, just to discover the key prevented it, and you need to reprompt the user again.
Unless, of course, you're doing all your validation with the DB schema (which is probably pretty close to possible, depending on your RDBMS). Here's a secret. I leave the key there, and don't even bother recovering from the error if it triggers. You violate that key, it's a fatal error. Sure, it's not perfect, and I suppose that I might one day piss someone off, but after working with my current application for 2.5 years (for some big clients, both government and private), it's never come up. cheers, barneyb On Wed, 3 Nov 2004 15:36:38 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > On Wed, 3 Nov 2004 15:18:19 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > locking the table, checking the new value against it, updating the > > table, and finally unlocking the table will give you guarenteed > > uniqueness. A CFLOCK in place of the table locks will work as well, > > as long as everything gets to the DB via the CF code. > > > > I'm not sure how you'd actually implement that? In a stored procedure? > Regardless, you'd basically be reinventing the wheel that is the > unique key. (and it would probably be less performant). That's what > it's there for so why not use it? > > > A key is the way to go, but you can avoid using it (which makes your > > validation code simpler and more straightforward) 99.9% of the time. > > > > Well, I have to disagree. I don't think you can avoid using it but > then my assumption is that if you want usernames to be unique they > need to be unique period and you have to do what you need to do to > guarantee that 100%. This reminds me of an article by Joel > (http://www.joelonsoftware.com/articles/Craftsmanship.html). > > > -Phil > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ I currently have 0 GMail invites for the taking ---------------------------------------------------------- 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]
