Best practices for updating production BE with structural changes made in development BE

[hansendl]

Hi all,
I'm curious how you all track and manage structural changes to the development BE (when adding new features/functionality to an application) and how you eventually implement those changes in the production BE? How do you keep track of all of the changes made to tables, relationships, indexes, etc.? I'm developing an app right now that I need to put into production for operational reasons right now. The app is minimally functional as is, but there's much more that needs to be added in order for it to be truly functional. I've tried to anticipate the table structure needed to support the additional functionality, but I'm sure there will be additional changes needed to the BE structure as I get into the FE development. Wanted to know what the best practices are for handling this issue.

Thanks!


Dean

[June7]

It may be best practice to keep track of changes but I don't. I do have an administrator's manual that I will modify if the changes are significant enough.

You might want to keep a journal.

I make changes to production backend only when I know no one else is in the db. If the changes mandate that code be in place in frontend then I make sure revised frontend is ready. This could mean evening or weekend hours for writing and debugging.

[hansendl]

Thanks for the reply.

So if you don't keep track of changes you make to the development BE from one version to the next, how do you know what changes to make to the production BE when you roll out a new FE?

I get that changes to the production BE have to be made when no one else is in the db, I'm just trying to understand how you keep track of what changes need to be made!

[June7]

I might have to keep some notes during any modification effort but once all is done I don't keep any historical records of the edits. This is not a large db and not a large staff. We are somewhat informal with procedures. You might need a more structured documentation approach (ie. CYA!).

I keep a master copy of the FE for maintenance edits. When I am ready to distribute new version, it is 'rolled out' at a convenient time. Review https://www.accessforums.net/code-re...end-33331.html

My major db is at a stage where seldom need structural changes. We are discussing adding a new field which can easily be done without impacting anyone using the db. I can then modify FE to accommodate the new field and distribute the new FE when convenient. Eliminating the use of a field or table is another matter, which should be a very rare event in any db. Could modify the FE without testing with BE and then make the BE edits just before distribution. Or make a copy of backend, do mods on and test the FE edits. Then when ready for deployment still have to make the same mods to the original BE because really don't want to be transferring data.

[NTC]

Notes. Very important notes. If one is making changes to the back end - in a development version - then you must definitely make very clear notes; so that when it is time to implement into the production back end you know exactly what to do.

After you make those changes to the Production back end - then you copy it and run the FE linked to the copy to put it thru its paces - and if all is well - then put the real Production BE in its place.

[hansendl]

Thanks, June7. I saw some code in Roger's Access Library (http://www.rogersaccesslibrary.com/forum/topic376.html) that compares the structure of two tables. I may try to modify the code to compare the entire data structure of the two BE versions to identify the differences. If that works, that approach would be superior to keeping a manual journal, and would be less prone to error.

Appreciate the response!

Dean

[Perceptus]

I store all my notes for databases changes in a Tiddly Wiki. Doesn't require a web server.

[hansendl]

Thanks, NTC and Perceptus. @Perceptus, what is a Tiddly Wiki? I've never heard of that--I'll have to Google it...

Cheers,
Dean

[Perceptus]

http://tiddlywiki.org

Happy to help