On Mar 18, 2009, at 11:52 AM, Jeff Schmitz wrote:
Barring that I was thinking maybe check both before and after the
save. If there did happen to be two after the save, I could add a
number after the filed to make it unique and save it again, of
course notifying the user of the new name. Of cou
Barring that I was thinking maybe check both before and after the
save. If there did happen to be two after the save, I could add a
number after the filed to make it unique and save it again, of
course notifying the user of the new name. Of course I'd have to
>
On Mar 18, 2009, at 5:15 AM, Jeff Schmitz wrote:
On Mar 17, 2009, at 7:23 PM, Chuck Hill wrote:
On Mar 17, 2009, at 4:12 PM, Jeff Schmitz wrote:
Hi Andrew,
Not being a database expert, I was wondering what you meant by a
"lock in the database"?
I think he means another field that is u
On Mar 17, 2009, at 7:23 PM, Chuck Hill wrote:
On Mar 17, 2009, at 4:12 PM, Jeff Schmitz wrote:
Hi Andrew,
Not being a database expert, I was wondering what you meant by a
"lock in the database"?
I think he means another field that is used as an editing lock. I
think this would sti
On Mar 17, 2009, at 4:12 PM, Jeff Schmitz wrote:
Hi Andrew,
Not being a database expert, I was wondering what you meant by a
"lock in the database"?
I think he means another field that is used as an editing lock. I
think this would still leave you open to a race condition.
I coul
Hi Andrew,
Not being a database expert, I was wondering what you meant by a
"lock in the database"? I could see using a Java synchronized object
for a lock, but that wouldn't work across application instances. My
problem is it is the user that is specifying the "unique" field
(unique
Hello Neil;
What I tend to do is to have a lock in the database and then the
thread adding the new code has to acquire the lock and write the
record before being able to unlock the the lock. Addition of a unique
index will also ensure that the column values are not duplicated.
cheers.
I
Hi Stuart,
Thanks for your reply.
The separate table is a workable solution. And I think that my stored
procedure can take care of all the housekeeping so that all WO has to
concentrate on is inserting the received value into a database:
something it does rather well.
I think that your s
Thanks for the suggestions.
__UUID__
The problem is that a UUID is too long at 32 hex chars, and shortening
a freshly generated UUID doesn't guarantee uniqueness any more.
__MySQL AutoIncrement__
This will then give me the next 'guessable' ID in the sequence, which
presents a security issue
Have you thought about using a Universally Unique Identifier (UUID)?
http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html
Regards,
Jake
On 21/01/2008, at 1:06 PM, Neil MacLennan wrote:
Following on from the postings on subject, "Avoiding duplicate
records" can I get my understanding
Following on from the postings on subject, "Avoiding duplicate
records" can I get my understanding right? (so that I don't waste any
more time trying to fix what can't be fixed):
I'm looking for, say, a six-character unique field in my database
record. I generate this randomly so that each
11 matches
Mail list logo
