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 ---------------------------------------------------------- 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]
