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.
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. On Wed, 3 Nov 2004 15:12:20 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > I know table locks work in that they prevent inserts while the lock is > active. I meant that it wouldn't work in the context of this > discussion to guarantee uniqueness. I'm glad we agree that the unique > key is the only robust way to guarantee uniqueness. It's not such a > "horrible option" after all. ;) > > -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]
