Concurrency checking?

[peterH]

Am I correct in assuming that's lacking in NTWS apps? (unless, of course, you write something yourself).

Peter

[kevin plummer]

I think you would want to restrict any kind of concurrency potential problems in an offline mode. eg if a user can change a vendor code a concurrency problem may be detected online but not offline. In an offline situation I would then restrict a user being able to change a vendor code or any other potential concurrency problems.

[peterH]

Hi Kevin,

This is an online situation, a task management system where task data is being accessed by both the company (my customer) and their customers. That's what got me started thinking about this.

Peter

[Bruce]

Hi Peter,

I think you would need to more specifically define what exact concurrency situation you had in mind.

cheers
Bruce

[peterH]

Hi Bruce,

Well, we're so used to automatic concurrency checking being taken care of by the ABC classes - and the well-known "This record was changed by another station..." message. But as I was playing around with a web app it dawned on me that even connected web apps need some sort of syncronization to handle a two-different-users-trying-to-update-the-same-record-situation. Of course, the nature of the specific application determines the actual need. But I think this is a fact being overlooked by many here - including myself ;-)

Peter

[Bruce]

Hi Peter,

>> Well, we're so used to automatic concurrency checking being taken care of by the ABC classes - and the well-known "This record was changed by another station..." message.

well, yes and no. ABC deals with the situation where two users both open the same record, make a change, then attempt to save the record. It only handles a fairly narrow window period.

It does not, for example, gracefully deal with 2 people changing the same field at the same time (even to the same value.)
In the ABC approach the first one to save "wins", the second person has to cancel.

But you are right, NetTalk does not even both to do this.

>>  even connected web apps need some sort of synchronization to handle a two-different-users-trying-to-update-the-same-record-situation.

it does deal with them <g>. The second person to hit save "wins". <g>.

In practice what usually happens is that people don't "change the same record at the same time". Which is why seeing "record changed by another station" is a very uncommon error on a desktop system, and most often means you've made a mistake in the code.

cheers
Bruce