We made a first 'datastore' converting a datawindow from Powerbuilder to Snapdevelop - and added a non-pb client frontend using the backend services.

Most of the functionality 'works' - but compared to Powerbuilder - we now tried a "multi-user" situation

2 users modifying the same record.

No matter which UpdateWhereStrategy we implement in the model the 'update" is always "accepted" by the database.

In powerbuilder - the second user would have had an error - 'row changed between retrieve and update' when trying to save

(because the data was already changed by somebody else)

But if we do the test in snapdevelop - both updates are always 'accepted'/'done' - resulting in the 2nd user overwritting the data from the first one.

(as the UpdateWhereStrategy would be based on the "KEYCOLUMNS" only)

The 'where' clause we see is however build correctly according to the "UpdateWhereStrategy" we specified - but seems not to work.

It's looks like the data is always retrieved/renewed (for the DB) again before the update is done - because no matter the UpdateWhereStrategy we never get any error back from the DB stating the update cannot be done. (because original data was changed)

In Powerbuilder we have the 'buffers' (original/primary) holding the different data - generating the sql's for the update - but this is a client-server app.

Here we have a separated frontend & backend - so how does/could the call to the update still 'know' which were the original values in the datastore?

So our conclusion of the problem:

The property UpdateWhereStrategy seems to be implemented/working looking at the 'where' that is generated when issuing the update - but seems to make no difference at all on the update towards the db itself - it's like the second update always sees/know that the data was changed by another user...

(and takes this into account already)