logo
  • Home
  • COVID-19
  • About Us
  • Products
  • Services
    • Microsoft Dynamics 365 CRM Training
    • Microsoft Dynamics 365 CRM Configuration
    • Microsoft Dynamics 365 CRM Customization
  • Resources
    • Blog
    • White Paper download
    • CRM for SMB
  • Clients
Contact Us 610.355.1978
Blog
Reasons for a Separate Test Environment with Database Applications
Posted on 05/16/2016

Issues Related to Testing on a Production Server with SQL:

No  Description / Explanation
1)Switching between Connection Strings
Many database applications rely on hard-coded connection strings to access the database. To test and run a database application in the same environment in this scenario, multiple copies of the database must be made with respective connection strings. These connection strings can become confused.
2)Switching Between Ports in IIS (if Microsoft)
The different versions must exist in different folders, which are accordingly pointed to different IIS (or Apache if not Microsoft) entries. These settings can become reversed. “http://localhost:85” may lead to the test version now, but a change an IIS can point that same entry to the production.
3)Easiness to Enter Wrong URL (end user error)
If on the same network, it is still possible to enter the wrong url (http://server1 vs http://server2) if one does not use localhost. It already has been noted that ports can be changed, but even without changing them, end user mistakes are easy. It is a larger error to mistype a url than a port. Additionally, security settings can knock undesired users out of the wrong server to prevent mishaps, which totally prevent the user from even being able to access the environment.
4)Queries with Hard Coded Database Names
Even with connection strings that are external, it is still possible to write queries (in SQL Server for instance) which have the actual database written inline, within the query. The connection string may be set correctly, however the query will still use whatever database it is written to use. The scenario of hitting the wrong server due to inline code is much less likely than the wrong database.
5)Stored Procedures which Cross Databases
Some applications utilize more than one database, which store compiled stored procedures. The stored procedures may have code that crisscrosses back between the two databases. With two instances of an application running (both with their respective databases), this potentially is a recipe for disaster.
6)Restore Point Mechanisms
Often different versions are switched between productions and live due to the specific needs at the time. A restore point mechanism, whether Windows System restore or another, could reset settings related to the application. Windows System restore does not interfere with data (only settings), but other restore point mechanisms may. With live data on the server, the risks are greater. Due to historical circumstances that changed, the test can become the production and the production the test.
7)Load/Performance
Without having a separate environment for the test system, slowed performance on production while running tests will always be a potential issue. To truly alleviate this problem, however, it may be necessary to have separate physical servers, not virtualized servers.
8)Being Present when Unrelated Problem Occurs
On a production environment, the potential exists for a problem to arise that has nothing to do with the changes being made by a particular user. However, the mere presence of the user is enough to bring initial suspicion, an avoidable scenario if the user is not there.

Categories

  • CRM Implementation
  • Database Applications
  • For Your Information
  • Office 365
Address

EBS, Inc.

1990 Sproul Road,
Second Floor, Suite B

Broomall, PA 19008

Phone

610.355.1978

Fax

610.973.7815

    Site Map Contact Us
    logo

    © 2015-2020, Ebs, Inc.,

    All Rights Reserved

     

    This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
    Privacy & Cookies Policy

    Privacy Overview

    This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
    Privacy Overview

    This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

    Necessary Always Enabled

    Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

    Non-necessary

    Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.