Actually, this will help a lot...I was wanting to split this docid data
out of the table it was in.
The reason I had added the locks was because one large client with 50
workstations was occasionally getting two orders added to the database
with the same Document ID value. The locks did stop that from happening,
but created the lock problem.
According to the reference you sent, and another page on the MySQL
website, these two lines
update saleorderid set id=last_insert_id(id+1);
select last_insert_id();
When combined with a simple, single auto-incrementing field will produce
the unique ID I need, with no chance of duplicates being returned even
with multiple simultaneous hits. And, it keeps a small table that stays
at just one record.
Thanks for the advice! It helps to break out of the FPro way of doing
things...
Mike
> On Sat, Jul 30, 2011 at 5:29 PM, Mike Copeland<[email protected]> wrote:
>
> What version, what engines? Different engines have different features.
>
>> This only happens on one form that DOES do a table lock, to obtain a
>> sequential document number. Here's psuedo-code...
>>
>> lock tables systemtable write
>>
>> select docid from systemtable
>>
>> update systemtable set docid=docid+1
>>
>> unlock tables
> You're working too hard creating locks when you don't need to. Try
> deleting both the lock and unlock and try this as a single-user to
> confirm that the errors in the following lines go away.
>
> Then, try some of the alternate suggestions here:
>
> http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
>
> My preferences would be a single column docid table with
> autoincrementing primary key. Let the engine do the hard work. Create
> a record every time you need one. If you care, truncate the table once
> in a while to keep the size under control.
>
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
