Making Changes to a production DB

[cybhunter]

I recently inherited an Access Db that is on a company server and is accessed by company emloyees through Citrix.

I currently make a copy of the DB and then make design changes to the copy. Once tested and ready for production, I then have to manually make my changes to the production DB. Pain in the butt and always have to hope I make all the changes to all the right places. There has to be an easier way.

I am learning Access so I can support this DB. I see there is a replication function in Access, should I be using that? My guess is yes, and I have played with this a little but there seems to be a snag in my DB. When you first open the Db the app wants to create an additional tool bar that has a few custom icons on it like log out and change profile info, etc.. This routine seems to have some code in it that replication doesn't seem to like.

When I try to open what would be the the production version of the Db (non-design master) it errors out and wants me to debug. If I rem out the routine that creates the new toolbar the application then opens. (Users can not do this nor should have to.)

I guess my question is Am I on the right path using replication and need to get some help debugging the toolbar code or is there a better way to get changes to the production Db other than manually? Thanks!

 

[PHV]

Is your DB split (FrontEnd and BackEnd) ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[cybhunter]

No it is not split. The users profile determines if they can see the user interface or if they have access to the design mode. Only I have access to design mode. This is just and Access DB on a server that users can get to through Citrix.

 

[acent]

Personally, I would split the DB first. I used to have qa production db in access and what I did was split it, then I wrote a small java program to update the users. My users didn't have citrix, they just had their desktops which had the front end and the back end was on the server.

The backend had a password so users couldn't get to it, and the front end was compiled to an MDE so users couldn't change the code. This provided decent security and allowed for development in a nice fashion.

This allwed me to do development without kicking everyone off the DB to update them.

"If it's stupid but works, it isn't stupid."
-Murphy's Military Laws