views:

71

answers:

2

Hi everyone,

I have a question but I'm not sure of the word to use.

My problem: I have an application using a database to stock information. The database can ben in access (local) or in a server (SQL Server or Oracle). We support these 3 kind of database. We want to give the possibility to the user to do what I think we can call versioning.

Let me explain : We have a database 1. This is the master. We want to be able to create a database 2 that will be the same thing as database 1 but we can give it to someone else.

They each work on each other side, adding, modifying and deleting records on this very complex database. After that, we want the database 1 to include the change from database 2, but with the possibility to dismiss some of the change.

For you information, ou application is already multiuser so why don't we just use this multi-user and forget about this versionning? It's because sometimes, we need to give a copy of the database to another company on another site and they can't connect on our server. They work on their side and then, we want to merge.

Is there anyone here with experience with this type of requirement? We have a lot of ideas but most of them require a LOT of work, massive modification to the database or to the existing queries.

This is a 2 millions and growing C++ app, so rewriting it is not possible!

Thanks for any ideas that you may give us!

J-F

A: 

This was already done by ical (an old SunOS calendar app).

What you store/remember/transmit when the app makes the changes is not just the database contents, but the actual change log (e.g. "delete record with ID 1", "update record with ID 2 with these fields", "insert record with these fields")

That way you can apply these changes to master DB later on, AND to filter them before applying

DVK
Thanks, this is also a great idea. We are doing this on one of our small application and it's very complicated to manage but it'a a solution to look.
DarkJaff
A: 

The term you are looking for is Database Replication. You can google that to get more information about the topic (my personal experience is limited).

Larry Lustig
`but with the possibility to dismiss some of the change.` will be difficult
KM
@KM: I doubt they'll find an off-the-shelf product. But the literature should give them information on how to go about journaling or detecting changes and moving the update information between database nodes. With 2M lines of code already, it sounds like they're willing to grow their own solution.
Larry Lustig
@Larry Lustig, I agree with `doubt they'll find an off-the-shelf product.`
KM
Thanks that help a lot. We'll keep analysing the implication on our database.
DarkJaff