copy data from "live environment" to "test environment"

Question Status

Verified
scottmik asked a question on 6 Jun 2017 9:08 AM

we have 2 GP environments live and test. I would like to copy the live environment data over to test environment.  can I just make a backup of the live database and restore over the top of the test?  should I also copy the dynamics GP directory from the live to test environment if I wanted to make sure GP settings are the same in both?

both environments are virtual so I could also take a copy of the live environment and place it on the test environment hardware but I am unclear what I would need to change in the test environment so as not to conflict with the live environment.

any suggestions are appreciated

Reply
Verified Answer
Béat Bucher responded on 12 Jun 2017 8:35 AM

Hi Scott,

The link MIcki provided is the standard process when you copy a PROD company over to a TEST company, within the same SQL server (i.e. you add a new TEST company with GP Utilities)..

When dealing with a whole copy of the server, there is another KB article that handles the whole process, though it's mostly targeted to companies that want to create a new SQL environment and want to "move" their production DB's to the new system, so not quite the same objective that you're looking for.

In your case, as you're virtualized, the easiest thing would be to create a clone of your server and rename it.. Be careful that you need also to rename the SQL server name and instance.. Standard process is available on the net for this common task.

With a separate dedicated TEST environment (not just a company), you're much more free to test other service packs or 3rd party modules (or new GP modules) without fearing to alter anything from the PROD environment. Many settings in GP are carried over in the DYNAMICS system DB, which is common to all the GP companies, even a TEST company.. so be careful when doing any settings changes in a TEST company that may affect the LIVE companies.

Be aware that your users won't be able to access your TEST enviornment SQL server with the regular GP client, unless you create a new ODBC connection on their workstation and use the exact same release of GP.. .As soon as you change the slightest modules or service packs on your TEST server, don't allow the users to connect anymore..

In an ideal world, what I do is share the GP client in Terminal Server mode on my TEST enviroment server, thus the users can connect thru Web RDP login and launch the GP client from the server directly.. so there is no risk of interfering with their exsiting GP client.

This way I can test upgrade to a new GP version/release and let the user test it out whenever they have time.

(Edit) PS: with a new SQL server, the name being different, you'll have to reset all your GP user's password, as it is encrypted based on the original ODBC linked server name..

Reply
scottmik responded on 19 Jun 2017 7:41 AM

thanks. this helped

Reply
Verified Answer
Béat Bucher responded on 12 Jun 2017 8:35 AM

Hi Scott,

The link MIcki provided is the standard process when you copy a PROD company over to a TEST company, within the same SQL server (i.e. you add a new TEST company with GP Utilities)..

When dealing with a whole copy of the server, there is another KB article that handles the whole process, though it's mostly targeted to companies that want to create a new SQL environment and want to "move" their production DB's to the new system, so not quite the same objective that you're looking for.

In your case, as you're virtualized, the easiest thing would be to create a clone of your server and rename it.. Be careful that you need also to rename the SQL server name and instance.. Standard process is available on the net for this common task.

With a separate dedicated TEST environment (not just a company), you're much more free to test other service packs or 3rd party modules (or new GP modules) without fearing to alter anything from the PROD environment. Many settings in GP are carried over in the DYNAMICS system DB, which is common to all the GP companies, even a TEST company.. so be careful when doing any settings changes in a TEST company that may affect the LIVE companies.

Be aware that your users won't be able to access your TEST enviornment SQL server with the regular GP client, unless you create a new ODBC connection on their workstation and use the exact same release of GP.. .As soon as you change the slightest modules or service packs on your TEST server, don't allow the users to connect anymore..

In an ideal world, what I do is share the GP client in Terminal Server mode on my TEST enviroment server, thus the users can connect thru Web RDP login and launch the GP client from the server directly.. so there is no risk of interfering with their exsiting GP client.

This way I can test upgrade to a new GP version/release and let the user test it out whenever they have time.

(Edit) PS: with a new SQL server, the name being different, you'll have to reset all your GP user's password, as it is encrypted based on the original ODBC linked server name..

Reply