From: "Ann W. Harrison" <aharrison@...>

> Woody,
>
>
> >I agree with this type of solution, however, reading data isn't really an
> >issue, only modifying it, except in specific cases.
>
> Yes of course writing is the problem, but if the application
> locks the record before presenting data to the user, it avoids
> making the user rethink his problem. You're quite right also
> when you point out that this particular issue, updating a counter,
> doesn't require any real subtlety. I don't understand what
> Danny means when he says:
>
> > I think too that generator is not a good option because the
> > counters would be consecutive 1,2,3,4,5.

If I'm not mistaken, I think (I am assuming here :) that he requires
consecutive numbers for each type of counter. One generator wouldn't do so
there would have to be a separate generator for each one. I do this myself
by maintaining a separate table containing ID values and the next counter
ID. I lock the table and then get the next ID, and update it for the next
person.

>
> Fair enough... I'm something of a fanatic on concurrency
> and consistency. Maybe for a beginner doing baby applications,
> serialized transactions that alter only one record each are ok.
> [Calm yourself Ann... crawl back into your cave.]

That's simplistic, I admit, but I didn't want to go into too much detail.
Basically, what I meant is that I only work with one master record at a
time. For example, all of my master queries return one and only one record.
I use stored procedures to retrieve the next, previous, or specific record
based on the current one instead of opening a complete recordset and
scrolling through them on the client side. Each time I retrieve another
master record, I can close the transaction and start a new one. That tends
to shorten the time they are alive.

I think we are both on the same page for most of this so we'll just let it
rest. <g>

Woody (TMW)