Understanding disconnected processing

[dRAMmer]

I just read about smart client applications, where in it utilizes off line processing, where in data can be taken offline, processed and then the application goes online again. I have a question about these, imagine I have this scenario:
A sales personnel encoded a sales order, disconnects from the server and added a few items on the SO. A user who has a right to delete SOs deleted that SO. The user-creator gets online again and saved the SO. What should happen?
1) An error will be sent to the user since the SO was deleted
2) A new SO will be created with the added items during offline
3) The SO should have not been deleted. This means even "admin" should have no rights to delete it.
- In this case how will the program knows which item the admin can delete
4) Any ideas and suggestions

Thanks in advance!

[jmcilhinney]

This is a concurrency issue. In the absence of any other checks you would get a concurrency violation when you tried to update the record, which means the version of the record in the database does not match the original version that your app is holding. You can handle the exception thrown under these circumstances and decide what to do from there. I'm sure that you could find plenty of literature to read regarding concurrency. I'm no database guru so I don't know all the ins and outs, but that's a place to start. The bigger databases may well also have functionality built-in to integrate various edits to the same record based on chronology.

[dRAMmer]

Hi jmcilhinney!

Thanks for the reply I know about concurrency, I was actually hoping to get an answer about what action to take. So I guess that leaves me "whatever business logic" is appropriate for the user or what the client wants.

[mendhak]

None of the above.

When the record is deleted, set a bDeleted field to 1, so that while the record isn't actually removed from the table, it's just got a bit set that prevents it from being used in normal mode in the program.

This will allow for two things

1. The update will occur.
2. The record will no longer be used by your application because the admin said so.

[techgnome]

E) Still none of the above

This is a business requirement that needs to be addressed by the client (users). What do THEY want to have happen? We could sit here all day and debate what WE think should happen, but the users may have a different idea all together.

Personaly, when the SO is grabbed by the user to be updated a check out flag should be set preventing deletion. When some one else access that record, then they should be notified that it is being edited and is currently locked. Once it's "checked back in" then it can be deleted. But I'd have to wonder why it's being added to AND deleted at the same time... sounds like there's a business rule that's being broken or not followed some where.

-tg

[dRAMmer]

Hi! THank you both for the reply, actually what you answered was simialr to #3. I guess I was not clear when I said "it should have NOT been deleted." Still suggestions given was very helpful, flagging was implemented already. But I still need on the details of this problem, I guess the SO example was quite general, or maybe not. Talking about the details, some items can be (or admin should be able to?) deleted even if those items are checked out. If items added to SO are flagged and it takes a while before it is checked in, the admin has no way to delete the items. What if the need comes that it should really be deleted and admin can't wait for the user who checked out the item? can't wait may mean that the user is offline (and has no way to be contacted immdiately ) ?