Not sure what to do in this scenario... Disconnected Application

reagan123 posted on Tuesday, April 15, 2008

Hi there.
Here is a quick description of my setup and issues... I'm lost on how to handle this.

I have 2 different modes of running an appliction.

Scenario 1. User hits a central database server and can perfomr basic CRUD operations (This works fine)

Scenario 2. User selects an object on the database server and chooses to work with it on an offline database.  Basically they choose an object and we serialize all the data they need to a file.  They then take that file to a laptop that has a blank of our database and we deserialize all of the objects to the blank database on the laptop.  This user  does their work on the object... and we basically reverse the process and it eventually goes back into the server.

Here is the big issue... It is possible for the users in scenario 1 to do work on the parent only (not the kids) and the users in scenario 2 can update the child information but not the parent.  I'm not sure how to allow this to happen without concurrency issues or the fear of overwriting data when bringing the disconnected data back to the database server.

Did that make sense??? 

Objects:
BusinessBase: Equipment (Scenario 1 can change)
Child: WorkOrders (Scenario 2 can change)
Child: PartOrders (Scenario 2 can change)

sergeyb replied on Tuesday, April 15, 2008

brucep replied on Tuesday, April 15, 2008

Reagan:

Sounds like you need your disconnected app to do a little more work. Specifically:

1. When disconnected, your Save() method must persist old/deleted child references.
2. You probably need to use Guids as some kind of surrogate key, for comparison purposes when resynching.
3. You will need some logic to do versioning, such as a stamp on each item, both parent and child. I typically only use stamps on parent objects, but that probably wouldn't work in the disconnected case.
4. Finally, you need to have a good Merge() method when resynching. The simplest case is you check the stamp of the parent object in the primary DB, and if it is lower (I use ints for stamps), then all is okay, just Save() as normal. If it is the same or higher, then you have to bring up some kind of comparison screen that shows the changes side by side and lets the user decide if they want to proceed. And of course in this case you must have some logic in the SPROC that will override the concurrency error that would usually result.

HTH,

Bruce

reagan123 replied on Tuesday, April 15, 2008

Thanks guys..

Bruce, You bring up an interesting concept.  What is the best way to compare 2 objects when doing something like this.

I'm still new to the framework and objects etc...

I really appreciate the help.

 

Sergey,
Everytime a record is saved in our database we update the DateTimeStamp.  I guess my issue here was if someone updated the parent record in the connected db then the datetimestamp was updated.  When I try to resync.. the disconnected datetimestamp was older and I would get a concurrency check error.  I guess this is a seperate problem... :)
Thanks for the reply as well

brucep replied on Tuesday, April 15, 2008

Reagan:

It helps to think of your parent object in a "wholistic" way (not sure if that's a word or not). In other words, if anything changes in a child object or the fields of the parent itself, the parent object should always be saved and have its stamp updated. In other words, even if no fields changed in the parent object, in reality its stamp did change, because the object "as a whole" changed. I'm fairly certain the CSLA framework handles it this way already, but I've been out of  the loop so long that I don't know. Somebody can enlighten me if I'm just preaching to the choir here.

Enough soapbox, though. A great example of very fast side-by-side comparisons of things is Red Gate's SQL Compare (www.red-gate.com). I can't say I know how SQL Compare works internally, but one of the best comparison tools in the .NET framework is Dictionary<K, V> which allows you to create a key-value pair collection and then compare with keys in the dictionary. So you would create a Dictionary for each of the child collections and then compare with the existing object in the primary DB in a side-by-side grid. Dictionaries are extremely fast, even for huge collections, and they eliminate the need for nested looping to compare two collections.

As for the comparison itself, there are a mind-bogglingly large number of ways to do it. The most code would be to just compare the fields yourself in a method. Another way would be to mark the persisted fields or properties with some sort of Attribute, and use reflection to compare only fields / properties with that Attribute.

I would suggest you download a copy of SQL Compare, if nothing else just to see how it works. I'll also give it a plug as being incredibly cool software that paid for itself the first day I bought it.

reagan123 replied on Tuesday, April 15, 2008

Thanks again... Some of that stuff is new to me so i'll do some research.

I appreciate it.

reagan123 replied on Thursday, April 17, 2008

Thanks again guys... New question/issue.

The way our program is setup is as follows.
The user has a piece of equipment in the connected system that has 4 workorders in the child collection.  This is displayed in a treeview.  The user selects a WO that they want for the disconnected environment.  Right know I bring the whole object and all (4) workorders... The user just wants the one WO they selected to come over.  Is this possible to only bring a few of the child objects and not the whole collection? 

My big issue is that the person who designed all of this left our group and now we are trying to figure out what's going on.

Example:
Connected System
Equipment
    |--WO-1
    |--WO-2  -------> User Selects WO2 to work on in the disconnected environment
    |--WO-3
    |--WO-4

Disconnected System
Equipment
    |--WO-2