How is this different from an auto-incrementing field? Is it a date/time field? Does it have the same issues as an auto-incrementing field (the possibility of being renumbered)?
No, it is totally different than an auto-increment field. Yes, every time you update the record the rowversion field is auto-incremented. Let's say you have a sequences table (as you do) where you store sequences for each field of each table that is to be sequentially incremented. You first read the value on rowversion for that record while extracting the corresponding sequence. Now before you update the sequence field with sequence+1 you check if the rowversion is still the same. If it has changed, then someone else has updated this record. Here is pseudo code.
Code: Select all
WHILE true
SELECT nextSeq, RowVer FROM sequences s WHERE table = 'customers'
UPDATE sequences SET NextSeq = s.NextSeq+1 WHERE RowVer = s.RowVer
IF recordsUpdated > 0 THEN exitLoop
END
The table data might look like this:
Code: Select all
Field Sequence RowVersion
--------------------------------------------
ClaimKey 16 177709
CustNo 31644 240408
ServTicket 5666 240409
InvNumb 50344 240555
And I thought GUIDs were NOT guaranteed to be unique. As I understand it, they just have a very low probability of collision.
Well, there are different GUID lengths. However, if it is to be printed or keyed, then it won't solve the problem.
I simply lock the sequencing DBF record for the table, read the next value, update it by 1, save it, and unlock it.
Yet another way to follow the KISS principle. In SQL you achieve this same effect by having the whole piece of code inside a transaction; i.e., this is what I described as transactions. Still, I rather have that coupled with a unique indexes.
As for being able to have SQL and non SQL installations, this is were ADS is hard to beat. Yourcode can be ISAM or SQL or a little of both with the ADS RDD. The limitation is that the free ads (they call it local sever) allows no more than 5 users and the paid version (they call it remote server) has a cost, albeit I find it to be the least expensive -for cost- SQL in the market.
Reinaldo
