Production vs Test

[Greg Hains]

Hi.

 

Im sure there are many discussions about this, but I am looking for some information about the best way to handle a test version of a database. 

 

I'm happy to use a separate set of data (different table), but use the same solution - so I don't have to amend layouts and scripts in two solutions instead of just the one. 

 

Can anybody please give me a pointer to a known good source of how best to handle this - a separation model.

 

Thanks in advance.

Greg

[LaRetta]

Hi Greg,

 

i'm unsure what you are asking, sorry.  Have you read through the forum designed for separation?  http://fmforums.com/forum/forum/16-the-separation-model/  Oh, LOL, you ARE here!

 

Both your Data file and your pristine master copy of UI should be copied to your Development server and the file references should be local (usually always).  In this way, you won't mess up production data during testing and you will not run into (or cause) record locks while you develop.  If your system ever crashes during development, trash the UI and grab another clean master.  It will be easy to bring a new UI up to synch with your current-version changes since you hopefully have kept meticulous details of every change as you go.

 

You must be sure to make any changes in production Data file precisely AND in the same *field-creation order and hopefully make those changes when Users are not in the system.  This is easy to handle by documenting every Data file change which you should always document anyway.  Or you can migrate the data (something I avoid since it opens possibility of error during imports and usually takes much longer).

 

So User scripts and layouts exist only within the UI.  The Data file's graph will only hold the minimal relationship to permit any auto-enter calculations or calculation fields (which should be kept to minimum anyway).  The Data file usually only ends up with a single entity-style relationship ( for passing auto-entering keys or default related data) and a few scripts or developer layouts and of course, proper security.

 

So perform your work on Development version then schedule a time when you can 1) make the changes (usually few) in the Data file and 2) replace the UI with your Development version.  There is another possible detail which should not be forgotten ... if any of your new processes require data be pre-filled with existing data or any of the Production data must be changed to adhere to new business rules being implemented, you must also perform those actions at that time.  The easiest way to handle that is to create a script in your Development UI which updates the data (be sure to error trap for record locks if Users must remain in the system).  

 

As you are designing in the UI, create a new script called Update Data (example).  In this script, I use comments to list all the changes which require data change and most times, I write the script steps at that too also as I add that functionality, while it is fresh.  In this way, you can test:  a) copy a latest copy of Data in to Development, b ) make the schema changes you have documented in exact order and c) run your script to update any data.  As Developer, you can then perform test runs to be sure the steps are clear and also to provide you with the time required from start to finish.  Then the results should be scrutinised both by Developer and Business to be sure the changes translate properly in your Development copy before moving it to Production.  

 

Once those three steps are done, you can move forward with your update with confidence.

 

* Added:  you could also include a gazillion of empty fields in every table so as to adhere to the same order but I see that as unnecessary and bloating when a bit of discipline in documenting does the job as well.

 

Added also:  BTW, I run recover on both a copy of Production and the development version frequently (sometimes every day).  Any indication of corruption and I revert to prior pristine UI.

[LaRetta]

Oh, one other suggestion, Greg ...

 

Since you have a list of UI changes, another good step is to then copy those changes into a clean copy of your Master UI and serve that up to Production instead.  In this way, all of your test scripts steps, field-definition and other development changes and testings etc which cause swiss cheese in your file, can be eliminated completely in a new master UI.  This is something I've started doing this past year.  In this way, your master UI experiences the minimum modification and remains as pure and perfect as possible (learned from Ray Cologon).

 

Also, never use Production UI as your master.  Always use your highly-protected and perfect version of your UI.  And whenever possible, work locally ... less chance of connection drop which you may not be aware of and which can damage your Development UI.

 

Now that I've drowned you, LOL, if you provide a more specific question, we will be happy to be more specific.  

[Greg Hains]

Hi LaRetta,

 

Thank you very much (sincerely) for the detail and effort you put into the response. It was good information. Whilst I am careful with my development and implementation, I can still learn more from people like yourself. Thanks.

 

The problem is that I didn't explain myself clearly in the first place. I titled it "Production vs Test".

I should have named it "Production vs Training", so that new users can be taken through the product using test data from the same UI. So we have 1 x UI but access one of two data sets - Production or Test.

I am thinking it has something to do with the login process, so that the "training_user_1" login accesses the training data rather than the production data, eg. with user "prod_user_1".

Unless there was some sort of trick that could be employed with the tables, then it was a case of copying the UI component of the solution each time it' updated, and then relinking tables again - sounds painful.

 

Sorry about dragging you through this again LaRetta. Did I do a better job of explaining myself this time? lol

 

Greg

[LaRetta]

I should have named it "Production vs Training", so that new users can be taken through the product using test data from the same UI. So we have 1 x UI but access one of two data sets - Production or Test.

 

It is easiest to copy both the UI and Data to a test location and provide the trainees with that URL. If you use local file reference, there will not be chance of error.  In fact you can include a conditional format on the top of the UI main menu to produce "TRAINING VERSION" in 48 pt red font depending upon the server or device ID so they don't forget that they are not in true data.

 

The problem with providing an alternate Data file reference (listing both) is that, if the Production data file is not available, the test file would open instead and Users may think it is real data - nothing will tell them otherwise.  And for training, Users SHOULD see the most current data anyway since it will be information they are currently learning about.  Simplest is to copy both files to a test Training environment and use local file reference.  Only with real data can one learn about a real system.  Just an idea.  :-)

[Greg Hains]

LaRetta.

 

I will look into these points in more detail and see how I go.

 

Many thanks for your time.  :-)

Greg

[volkovpunk]

I use :

1) special account or accounts for testing

2) custom function TEST which returns 1 ( if current account is one of test accounts) or 0 in other cases

3) special flag (test_flag) in all recods, auto-enter calculation by creation = TEST. So I can define records created by test accounts

4) privilege settings: view records if test_flag = TEST

5) start script should find only visible records in each table.

6) Instead of "Show all records" everywhere i use GTRR or Perform Find to eliminate invisible records from foundset

[LaRetta]

I would never be comfortable combining test  (training ) data and production data in same tables.  :-)

Reporting, for example, depends many times upon all data and one would always need to omit test data from finds and filter relationships.  It would not be dependable and would require quite a bit more resources to remove test data at every turn.

[Greg Hains]

Hi LaRetta,

 

So are you saying that you would have scripts (in a single UI solution) effectively managing which tables (live or training) the logged in user (live or training) accesses?

[LaRetta]

No, as I suggested originally, I would use local reference and copy current UI and Data to another server and reference it THERE when training.  I would never create different tables just for training - that would not work at all.  Nor would I allow training to be performed within live data.