Considerations for Creating a Lims Test Environment on SQL Server

Creating a Lims Test Environment on SQL Server

Benefits of having a test environment:

1.         Run thru upgrades there first

-   You can run the Lims upgrader against the test Lims application and database.  Any errors can be handled prior to running against your live machine, allowing for a smooth upgrade on your live machine when you are ready.

-   Allows you to test out new/improved features of the application and become familiar with them, so that when it comes to upgrading your live production version, users will already be familiar with the version differences.

2        Allow users to experiment with Lims without repercussions. 

-   If a user shows interest in perhaps Lims administration, or a change of position/responsibilities, you can set up appropriate permissions on the test Lims so the user can explore without repercussions.

3.        New user training

-   A great place to train new users.  They can anything without messing up Live data or statistics


Things to consider when implementing a test environment:

1. Separate machine(s)

This keeps the two database’s (live vs test) completely separate.  You do not what to   accidently enter test data into a live Lims db, and vice versa.

2.   Separate database

Is there room on the existing server ?

Will your IT dept support backups and restores of the test database without too much headache?




3      You can get SQL Server Express (free) installed on the machine you intend to use for the test environment

Do you know how to backup/restore a SQL database? So that you can do this on your   own without needing IT intervention


Database to use

Existing Live db copy – this allows you to use your current services and cases

Empty database – this allows users to set up everything from scratch


Steps to point to a test database:

1. Restore what you will be using as a test database

2.  Recommend calling it sqllims_test (or something that you can easily identify as a test database)

3.   Install Lims application onto the test machine(s) (see customer support if needed)

4.   Point the ODBC on the test machine(s)to the sqllims_test database


Keep the original backup (that you restored) on the test db server.  You can continue to restore this over the existing database as needed.  It will bring you back to a known starting place (removing all prior work after that known point).

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request


  • 0
    Robert Grant

    We have had good success in running a test envoronment in parallel with our live production system for years.  We maintain two separate databases (SQLLims31 and limsplus), separate folder structures for imaging, staticdocs, etc.  We also maintain two separate sets of lablink files confiigured to point to the test and live dbs via Demo31 and SQLIms31 ODBC connections on the workstation.   We can use one separate c:\jtrax folder with either the same lims-plus exe or different ones, if we are testing a new build.  The secret is to have two subfolders under c:\jtrax called Temp and DTemp (one for the live and one for the test system).  Separate config.fpw files (config-l.fpw and config-d.fpw), again for the Live and test system:

    Live: config-l.fpw:


    Test: config-d.fpw:


    The difference in the files point to the lablink folders (DEFAULT=), as well as the PATH=, and the RESOURCE and TMPFILES parameters force the systems to use one of the two temp folders for report templates and preferences, so you can also test new reports.

    Each is launched by the icon properties:

    Live: C:\Jtrax\LIMS-plus.exe -c"c:\jtrax\config-l.fpw" or

    Test: C:\Jtrax\LIMS-plus.exe -c"c:\jtrax\config-d.fpw".

    If you need to test a new exe just change the name of the new exe (eg: LIMS-Plus-3719.exe) and change the icon properties to suit.


Please sign in to leave a comment.
Powered by Zendesk