backend version control?

CarlRostron

Registered User.
Local time
Today, 13:28
Joined
Nov 14, 2011
Messages
88
Help needed please on a split database (front and back end). I have completed the split and have deployed the backend to SharePoint. The front end is sat on my (and others) machines with linked tables to the SharePoint lists. This is all fine and works well.

However this is where I need help. Although this database is deployed, I am constantly working on a local copy of the database in design I.e. Tables being updated with fields and relationships and new tables being added. The reason for this is that work wanted something workable putting out there now and that I just continue its development in the background.

What is the best way to update the tables on SharePoint bearing in mind that users are putting new data on there? I don't want to lose what they are updating and then I need to redploy the 'new' backend to SharePoint again (no doubt in the same location) as that's where the front end is looking for it.

I hope this makes sense and I look forward to some guidance on how I can manage this version control of the backend without losing data.
 
Well you can append all the data from the production copy to your local copy then push your copy and overwrite the one on sharepoint. Aside from that there really isn't a great way to do version control and preserve data. Ideally a back end shouldn't be changed once it goes to production, I understand it wasn't your call in this case.
 
Yes far from ideal but I appreciate your words.
 
I don't use Sharepoint but I have a similar situation with an application that I support. It is sold to the public so once it is installed it is out of my control. When I have to make changes to the BE, I create a special update database. in it I have code and/or DDL queries that create columns or tables. Occassionally they add/drop constraints. The client is instructed to backup the BE and then run the BE-updater before deploying the new FE.

There is no easy way to generate the code to implement the changes but I stumbled across a way to automate parts of it. I found a tool that will compare two SQL Server databases (it handles other RDBMS but sadly not Jet or ACE) and generate differences and then the DDL to make dbA look like dbB or vice versa. I upsize both versions and then run the tool. I then copy the generated code into a text editor and make some minor syntax modifications to get Access to accept it. The final step is creating VBA to run the DDL queries to automate updating the client's database.
 

Users who are viewing this thread

Back
Top Bottom