Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Yet another Unique Key generator
Message
 
To
21/11/1999 11:58:14
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00293537
Message ID:
00293718
Views:
21
>Actually, lock (in counter table) is requried if you want to get 100% unique value for primary key immediately.

Nothing is going to return a value "immediately", something has to execute, right? I think it will return a unique value quicker than when using locks.

> However, if you prefer to beat table down until you will really get correct key, i.e. get first one, try to update, trap the error if not unique, get next value, update again etc.

The alternative is to keep checking for the record to become unlocked.

> It will also work, why not, but what the purpose? Locking is not really bad, and SQL-Server also uses it, behind the scene most of times.

Most of the time, the process will be 1. get value, 2. update. This will always be quicker than 1 try to lock, 2. test for success, 3 get value, 4 update, 5 unlock. (I would hope that VFP can lock/update/unlock quicker than I can). The only time I can see it being equal or slower is during a collision, which is the exception, not the norm.

> Do not take me wrong. If it works for you, that's good, but in reality there is nothing to prove here.

What I am asking for is "can anyone show me anything wrong with this?" So far, you and Craig have given me your hunches (and worded them as facts), but no support. At least you seam to have acknowledged that you think it will work, correct?


>
>>Can either of you please support your claims? I am not locking, because I don't need to lock. Locking takes time, locks get left in place, locks cause things to wait, and locks are not as portable to an SQL server. (I don't necessarily want to use an identity field.) Also, algorithms that use locks need to flip the alias around, and you then run the risk of it not getting flipped back to the right one.
>>
>>So, do you guys still think it can fail? If so, please show steps.
>>
>>
>>>This is for SINGLE USER only. In multiuser environment you would have to lock the highest key until after you inserted and updated the new record.
>>>Why don't you just have a primary key table with tablename C and nextid I fields, look up the tablename you want to append to, lock it, add one to nextid and unlock it and then use this as the primary key for your data table.
>>>Peter
>>>
>>>
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform