Test/dev and production environment (1 Viewer)

Derek

Registered User.
Local time
Today, 02:30
Joined
May 4, 2010
Messages
234
Hi guys ,

I have been using ms access for years and for any small change requests from clients like adding value in lookup table etc.. I never made test environment ready and added values in production lookup tables straightaway. But in my company they want test , dev and production environments to be created and used . Can anyone please provide me useful information on it ?

Any help will be much Appreciated .
Thanks
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:30
Joined
Oct 29, 2018
Messages
21,358
Hi. Are we talking about an Access backend?
 

Dreamweaver

Well-known member
Local time
Today, 09:30
Joined
Nov 28, 2005
Messages
2,466
Seems to me they want him to start using diffierent files I.E.

Development
Testing
Production

these would be 3 different versions the production being the one everybody uses
the testing may be given to a few employees to spend time using but not linked to the main datafile

I use a 2 tier system I.E. Development and production in my case I do the testing in the development stage as I don't have anybody else to do it.


hope if helps


mick
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:30
Joined
Oct 29, 2018
Messages
21,358
Got it. I was just wondering if it's possible they were wanting a dev/test/live SQL Server backend, because it's a little different to handle than a simple Access file as a backend.
 

Derek

Registered User.
Local time
Today, 02:30
Joined
May 4, 2010
Messages
234
Hi guys , I’m talking about access backend . Thanks
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:30
Joined
Oct 29, 2018
Messages
21,358
Hi guys , I’m talking about access backend . Thanks
Hi. Thanks for the clarification. I am not sure what kind of help you need, but maybe this demo could be a good start. Cheers!
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:30
Joined
Feb 28, 2001
Messages
27,001
I worked for the U.S. Navy as a contractor for years. They demanded separated files and environments because production outages would potentially affect a lot of folks. They applied that to big systems and small systems. (To be clear, mine was a smaller system.)

What you do is you have a fully secured, ready-to-use production front-end linked to your production back-end. That goes in your production folder. What your end users see is always from the production folder. File permissions allow them to do what is needed in the production folder.

BUT... you have at least two more environments. (I had three more.) Something that you are building is built in a private folder and that FE/BE combination is NOT fully secured. Because your users never touch the development area, file permissions will block them out totally, but you have full control. You do what you have to do with the "dev" copy. Edit, play with it, etc. Eventually, you have a copy you think will be stable enough to try it out. So you promote it to TEST.

In the Test environment, you have a nearly secured FE/BE. "Nearly secured" because you allow yourself to open that TEST copy with the BYPASS keys because you have not yet disabled the SHIFT BYPASS feature and any other things you might do for the "prod" copy. But the links to the private TEST back-end are there. As to how many people there are in this folder? All of your testers - and you - have access but your end users do not. If the tests fail, back to the DEV copy. If all is good with the world, you are ready to promote.

I built a staging area where I could do what I needed to do on the copy of the DB that had passed all tests. It was in this STAGING area that I finalized all links to the PROD back end file and set the Opening Menu and locked down the SHIFT BYPASS feature and any other restrictive things I needed to do. When all was well, I then copied from STAGING to PROD and notified all users that a new copy of the FE was available. I could not use the automatic updating batch job because my Navy IT guys had this thing about scripts. When I was done, the fully secured copy of the app left over in the STAGING folder became my backup copy.

Doing it this way, as long as I was ONLY changing FE stuff, I never had to take down the DB. But if a new FE change required a BE change, I would take the DB down, work on the BE file in one of the other areas, and eventually replace the old BE file with a newer version of same.

By having the DEV, TEST, STAGING, and PROD folders, I was able to keep things very tightly organized and at the same time, keep the Navy brass happy. Worked well for me.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 09:30
Joined
Sep 12, 2006
Messages
15,614
All you need is a copy of the data from time to time in a separate folder as test data.

you can then run your code database against the test data to evaluate programme changes.

Keep copies of code databases as you make changes, so you can manage production releases.

It sounds like you have this.

I don't quite understand the 3rd level, but maybe the company want to evaluate and confirm changes formally as final acceptance, hence the differentiation between "test" and "development". I think maybe they will want to do that, rather than you.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 05:30
Joined
Feb 19, 2002
Messages
42,981
I've worked for clients with EIGHT levels from test to production. Most are satisfied with three. The minimum of course is two.

The point Derek is that you will need to include relinking code in the app itself. This isn't something that the user will ever do but you need to be able to do this as you move from one environment to another. If ALL your linked tables are in ONE BE, then the linked tables manager will work file. However, once you have more than one source for linked tables, the process becomes more complex and the LTM just doesn't cut it although the latest version has gotten much better.

This sample checks for the presence of a specific linked file name in the frmCheckLinks (you need to change this for your purposes). If the file is found, the login form opens. If the file is not found, the relink form is opened.
 

Attachments

  • RelinkMultipleBEwithValidTableTest.zip
    97.8 KB · Views: 100

Users who are viewing this thread

Top Bottom