ralph
3/11/2012 2:45:00 PM
On Sat, 10 Mar 2012 22:42:33 -0500, "MikeB" <m.byerley@frontier.com>
wrote:
>
>"ralph" <nt_consulting64@yahoo.net> wrote in message
>news:fpvnl7159uemcgbeaoscqa7dr3658l53ib@4ax.com...
>> On Sat, 10 Mar 2012 12:18:14 -0700, Tony Toews
>> <ttoews@telusplanet.net> wrote:
>>
>>>On Fri, 9 Mar 2012 13:30:32 -0500, "MikeB" <m.byerley@frontier.com>
>>>wrote:
>>>
>>>>> A question that just kind of begs answering though is why are you even
>>>>> concerned about this? So what if some numbers are skipped? Your program
>>>>> shouldn't be dependent on them having to be sequential (and it doesn't
>>>>> sound like it is, so that's good).
>>>>
>>>> Usually this numberthink is related to OCD (I can sympathize), but a
>>>>numbering scheme in a database should hold no realworld visual meaning.
>>>>Even if it were to hardcode the sequencing of the records, out of
>>>>incidence
>>>>numbers work the same.
>>>
>>>While I don't mean to pile on I was thinking exactly the same. In
>>>Access missing autonumber values happen all the time if a person
>>>starts to enter a record in Access and then backs out of the form.
>>>But the users should never see that autonumber so no big deal.
>>>
>>>(That said I do expose the autonumber in one case but just as a visual
>>>aid.)
>>>
>>>Tony
>>
>> To add to the pile <g> ...
>>
>> It should be pointed out that while Access will do it its best to
>> insure integrity and uniqueness when requested - it (like all
>> databases) will never guarantee concurrency.
>
> Ralph,
> Exception to "all" databases.
> You should go back and read the history of RBase.
> Concurrency control is at the engine level and is absolutely guaranteed.
>
Ha. Well one can always get into trouble when they say "all", and
equal misfortune can fall to one that doesn't fully explain their
usage of a term.
Database concurrency is generally defined as the ability of multiple
users to read or write the same data at the same time with out
collision issues (excessive blocking or loss of integrity). Many RDBMS
provide for the user to setup and manage concurrency with locking
schemes, others facilitate the process with built-in "concurrency"
algorithms and options. R:Base, as you noted, was one of the early
adopters of the latter. SQL Server, on the other hand, didn't provide
a specific "currency" option until later in its career (2005?).
However, there is another form of "concurrency"; the ability to insure
any record is located (logically or physically) at an exact ordinal
position, or that sequence numbers (autonumbers, etc.) are applied in
order (in sequence without 'gaps'). That kind of concurrency is never
guaranteed by any database and any assumptions that it is some how
inherently handled always leads to surprises and disappointment.
Any time there is a requirement for a specific ordinal arrangement
then that requirement must be specifically designed for.
-ralph