Split Database Development

[Guest]

I have a split database that is in production.

Current development is on a backup of the FrontEnd of the Database and in
the evening development on a backup of the Production Tables. I than link the
tables and make a MDE of the FE and update the site with the new database.

My question is the new code has move away from the original presplit
database. It seems to be working ok but I'm concerned that down the road
something is going to come up which causes me to go all the way back to the
presplit database.

Any suggestions or advice is appreciated.

 

[Keith Wilby]

I have a split database that is in production.

Current development is on a backup of the FrontEnd of the Database and in
the evening development on a backup of the Production Tables. I than link
the
tables and make a MDE of the FE and update the site with the new database.

My question is the new code has move away from the original presplit
database. It seems to be working ok but I'm concerned that down the road
something is going to come up which causes me to go all the way back to
the
presplit database.

Any suggestions or advice is appreciated.

In my experience the "classic" development scenario is this: you have a
"production" backend to which your development and production FEs are both
linked. You code your development FE and, once tested, you deploy it as the
production version. If you have to work on the tables and relationships,
you lock your users out, work on the BE, test it with your development FE,
then allow users back in with the latest versions.

That's how I do it at any rate and it works flawlessly.

HTH - Keith.
www.keithwilby.com

 

[Marshall Barton]

I have a split database that is in production.

Current development is on a backup of the FrontEnd of the Database and in
the evening development on a backup of the Production Tables. I than link the
tables and make a MDE of the FE and update the site with the new database.

My question is the new code has move away from the original presplit
database. It seems to be working ok but I'm concerned that down the road
something is going to come up which causes me to go all the way back to the
presplit database.

It's your job to make changes that do not "require" you to
go back to the unsplit version.

Making changes to the data tables and/or relationships in
the backend is the serious issue here. If you have total
control over the backend so you can take it offline for
however long it takes to modify the structure, test, deploy
the frontend and then bring the backend online, then you are
in an enviable situation ;-)

However, the day will come when you have to make major
modifications that will require extensive changes to the
backend. Regardless of how careful you are in writing down
all the changes you make to the backend's back up copy,
there is a reasonable chance that you will make a mistake
when applying the same changes to the live version of the
backend. To avoid that kind of potentially catastrophic
mistake, I use an UpdateBackend procedure (usually in a
separate update mdb file) that makes the changes using DAO
code and/or SQL DDL statements. As modifications are
needed, I add code to the procedure that operates on the
test version of the backend. Once all the frontend, backend
and update procedure are completed and thoroughly tested,
the same update procedure can be applied to the live version
of the backend when the new version of the frontend is
installed.

 

[Guest]

Thanks for all the responses and you guys made my day.