The purpose of this document is to explain the Microvellum recommendation for sandbox testing, training, and production environments. To configure a sandbox environment, click here .

Microvellum strongly recommends a workstation dedicated to sandbox testing and training that is separate from your production workstations!

The reason for this recommendation is to minimize downtime and maximize production, to get the most out of your Microvellum investment. Also, this article will discuss how to manage the various environments being suggested.

Microvellum recommends that the data be managed or overseen by qualified individuals, either by an in-house IT department or outsourced to IT professionals. We recommend that IT personnel be included in all aspects of Microvellum Integration and Deployment for direct onsite support for data, infrastructure, and workstations that Microvellum Software will operate on. For companies that do not have these types of resources available, this document will serve as a guide to help you develop your system and guide you through essential aspects. Microvellum also offers additional services to assist, manage, or provide configuration and hands-on direction to meet your specific needs to create a customized Testing-Training and Production System.

Your Microvellum Software is composed of two parts, the software and the data .

The software can be uninstalled and reinstalled without issues, on as many workstations as your software license allows. You will need the installation files if you will be uninstalling and reinstalling the software.

The data , as opposed to the software, must be managed much more cautiously. The data is critical to the operation of the software. It contains all the information for your library products, reports, projects, tool files, etc. The data has a value from the initial installation and reflects a portion of the software purchase; value is added over time as it is used. As you create Custom Products, Shop Drawings, Work Orders, and other items, these items are recorded within one or more database(s) or other files.

It is imperative to ensure that valid backup and maintenance procedures are in place to safeguard your data from loss or damage.

Microvellum Data Folder

Microvellum uses the Microvellum Data folder to house system folders for various activities and data files. When configured to use a Compact Database, Microvellum looks to the Microvellum Data Folder to access the corresponding SDF file. The databases are the second part that makes up the Microvellum Data (databases will be discussed further in the next topic). The Microvellum Data Folder can be located at any specific location accessible from the Workstation.

Changing the Path to Microvellum Data

Examine the following image for the typical contents of the Microvellum data folder as displayed in the Windows File Explorer app.

There are different levels of data to consider. Generally, there will be test data, training data, and production data. We will refer to these types throughout this article. There is an additional level of data that can be referred to as the Master Dataset. The Master Dataset is developed over time as Integration and Deployment of Microvellum Software is completed. The Master Dataset reflects a baseline condition where all processes from engineering to production are functional, and the final version of your configured data exists. A copy of this data should be backed up and stored for safekeeping in the event of a system crash. If your system crashes and all your data is lost, the Master Dataset will be the source of the data you will use to begin rebuilding your entire engineering and production systems.

Database Overview

Databases are used to organize and store various data. Microvellum uses databases to contain all the data in your libraries, the data in your work orders, and everything in between. Databases consist of tables which contain data in columns and rows. Each column may also be referred to as a field, and each row may also be known as a record. Each column or field is configured to contain data of a specific type. The data type determines how much disk space is reserved for the data entered into this field; this will be helpful to understand when the Database Maintenance is discussed later in this document.

SQL Databases are relational databases. This is important to understand when working with reports in the software. In simple terms, it means that tables are related to each other and can be linked together. It is possible to manipulate the data that is housed in the databases using third party reporting software such as Stimulsoft or Crystal Reports. Even other ERP Systems can be integrated to use SQL data, if compatible.

There are currently two database types that Microvellum supports, SQL Compact and SQL Server. It is essential to understand the compatibility and limitations of each type.

SQL Compact

The first SQL Database we will discuss is SQL Compact. This is a standalone file with a file extension of SDF that exists in the Factory Database folder in the Microvellum Data folder. SQL Compact will only allow access to one user at a time, so it cannot be shared on a network drive between multiple users. SQL Compact is a portable database, meaning the SDF files can be copied and pasted like any other file on your computer or from computer to computer. It is important to note that SQL Compact is limited to 4GB in database file size. Once the 4GB limit is reached, the database will become inaccessible through standard interfaces; this is true for other database types as well. The easiest fix for this is to install SQL Server to allow more space using the Transfer Tables utility discussed later in this document.

SQL Server

The second type of SQL Database is SQL Express Server or SQL Server. The difference between the two is that SQL Express Server is a free version where SQL Server requires an additional purchase from a Microsoft reseller.  SQL Express Server is limited to 10GB in database file size, where SQL Server is unlimited. There are also some additional management tools available in SQL Server over SQL Express Server. In most instances, SQL Express Server will suffice for the regular operation of Microvellum Software. Other than the items previously noted, they are the same for Microvellum purposes. We will be referring to SQL as the SQL Express Server throughout the remainder of this document. 

Data Backup

Microvellum recommends regular backups to prevent data loss and for Disaster Recovery. A daily backup, in addition to a series of weekly or monthly backups, is recommended. This strategy of backing up data will ensure that the maximum data loss to be expected would be not exceeding more than 24 hours during a workweek. The series of weekly or monthly backups will allow you to retrieve data from the past. In rare instances, data could become corrupt; daily backups will capture corruption if the problem is not identified immediately. This type of corruption may not be detected for several weeks or months. The weekly and monthly backups will allow you to backtrack through time and find where the corruption occurred and retrieve the lost data.

A weekly and monthly backup schedule is highly dependent on the amount of disk space available on the backup device or storage location. With a regular archive and maintenance schedule, you could expect the total size of your Production Data to vary between 5GB to 10GB during a year for a medium to large size Cabinet Shop. This includes all data from databases and the data folder. Given that, to calculate the required disk space to determine the numbers of backups that can be performed, figure 10GB per backup. If space is available, Microvellum recommends one daily backup, four weekly backups, and six-monthly backups. This type of backup schedule will require 110GB of disk space.

It is crucial to back up your Production Data before deploying QFE’s or implementing other system changes in addition to scheduled backups.

There are many types of third-party Backup Software and Services to automate the Backup Schedule. Automated Backup Operations should be tested after deployment and periodically to ensure the backup Operations are valid.

Testing, Training, and Production Environments

After reviewing the previous information presented, you now have a general understanding of the folders and databases that make up your Microvellum Data and will now be able to set up custom configurations for various tasks. We will focus on creating and maintaining a configuration specifically for Testing and/or Training purposes and a configuration for Production. During the setup of your configurations, you are encouraged to document all critical information that would be required to rebuild your entire Microvellum System from scratch or direct access to crucial information such as activations, users, and other useful information. More detailed information on documentation procedures and strategies are discussed in the link provided below.

Network Infrastructure Documentation Overview

The purpose of the separate configurations is to isolate expendable data for Testing and/or Training from the Production data. Microvellum recommends an entirely different Test/Training workstation(s) in addition to the Production workstation(s) to maintain a normal Production Work Flow at all times. In some cases, a separate Testing-Training workstation will not be available. In these cases, a single computer will play the role of Primary workstation and Test workstation determined by switching between configurations as explained for Testing-Training and Production later in this document. It will be imperative that the user performing any testing procedures knows which configuration Microvellum is currently set to. Failing to do so may result in faulty test results and compound into other indirect issues.

Any changes in addition to software updates that may impact normal production flow need to be evaluated before deployed. These changes include such items as Server upgrades or replacement, replacing all the Production Workstations at the same time, introducing new users to learn on Production data, changing the names of shared folders, and so on. These types of changes are out of Microvellum Software’s control and are user-specified. Failing to evaluate such changes to ensure proper deployment and configuration of any changes may result in an interrupted Production Work Flow for an undetermined cause for an unknown amount of time.

Testing and Training configurations will allow a lab environment to investigate and evaluate such changes as previously noted. New Users going through Training should not work with Production Data until they can perform routine operations effectively. Being that the Testing and training data is expendable, it may be rebuilt from the Production data at any time for testing and training purposes to generate Live simulations with real-time data. Microvellum recommends that only experienced and knowledgeable Microvellum users either perform or oversee the testing process. For General Testing, the procedure is similar to the procedure as outlined in (QFE) Software Update Test Procedure discussed later in this document, with the exception that you will apply your change in place of applying the QFE.

Software Update Test Procedure

To ensure a normal Production Work Flow, Software Updates are recommended to be tested before deploying the update on Production workstations. Below are the general procedures to check an update before deployment.

Separate Test and Primary Workstations

1. On the Primary workstation, with Microvellum open, use the Transfer Tables utility to transfer the Production data from SQL Express Server to SQL CE located in the Factory Database folder for the Test data Microvellum Data folder path from the Primary workstation under the Production configuration.
   
For Step 1, the SQL database size must be smaller 4GB, the file size limit for SQL CE. 
2. On the test workstation, with Microvellum open, use the Transfer Tables utility to transfer from SQL CE located in the Factory Database folder for the test data’s Microvellum Data folder path to the testing SQL Express Server database.
   
3. Shut down Microvellum, run the update and restart Microvellum.
   
4. Check for general functionality, such as opening Projects, Drawings, Specification Groups, Product Properties, and Part Properties.
   
5. Check for specific functionality. If there is a particular feature of Microvellum that is used more frequently for normal Production Work Flow, those features are recommended be run through a quick simulation reflecting normal conditions.
   
6. General Simulation:
   
1. Run through a new small test Project with a Wall and a few Products.
   
2. Generate a Work Order.
   
3. Process the Work Order.
   
4. Review Reports.
   
5. Review G-Code.
   
6. If any issues are encountered during the Testing Procedure, DO NOT deploy the QFE on any other workstations. You are encouraged to submit a ticket to Technical Support to review the issue(s). Meanwhile, your Production will continue as usual until another QFE is released to address the issue(s). Proceed to Step 1 of this section when the next QFE is received.
   
7. If the testing verifies successful functionality, you can determine a schedule to deploy the QFE on all Production workstations. Be sure to back up all the Production data before deploying the QFE to update all Microvellum Products to the same version.
   

Single Test and Primary Workstation

1. Back up all the Production data before any testing occurs.
   
2. On the Primary workstation (Production Configuration), with Microvellum open, use the Transfer Tables utility to transfer the Production data from SQL Express Server to SQL CE located in the Factory Database folder for the Test data’s Microvellum Data folder path from the Primary workstation under the Production configuration.
   
3. On the Test workstation (Testing Configuration), with Microvellum open, use the Transfer Tables utility to transfer from SQL CE located in the Factory Database folder for the Test data’s Microvellum Data folder path to the testing SQL Express Server database.
   
4. Shut down Microvellum, apply QFE, and restart Microvellum.
   
5. Check for general functionality, such as open Projects, Drawings, Specification Groups, Product Properties, and Part Properties.
   
6. Check for specific functionality. If there is a particular feature of Microvellum that is used more frequently for normal Production Work Flow, those features are recommended be run through a quick simulation reflecting normal conditions.
   
7. General Simulation:
   
1. Run through a new small test Project with a Wall and a few Products.
   
2. Generate a Work Order.
   
3. Process the Work Order.
   
4. Review Reports.
   
5. Review G-Code.
   
6. If any issues are encountered during the Testing Procedure,  DO NOT  deploy the QFE on any other workstations. You are encouraged to submit a ticket to Technical Support to review the issue(s). Meanwhile, your Production will continue as usual until another QFE is released to address the issue(s). 
   
1. Now you will need to get your workstation back to its previous state. Shut down Microvellum, apply the last QFE known to yield satisfactory results, restart Microvellum and change back to the Production Configuration. Proceed to Step 1 of this section when the next QFE is received.
   
2. If the testing verifies successful functionality, simply change back to your Production Configuration and resume operations as usual.
   

Project and Work Order Archive

As previously mentioned, the database file size is important to track and manage. Scheduling regular intervals to identify the Projects and Work Orders for archiving will help reduce database file size for extended periods. Perhaps reviewing and archiving Projects that are over a year old and out of warranty twice a year and removing Work Orders six months old, for example. A standard procedure is required to prevent data loss or damage.

Database Maintenance

Scheduling regular yearly Database Maintenance is recommended. Database Maintenance consists of running a Compact and Repair utility for Compact databases and running a Shrink utility for SQL. Running a Compact and Repair or Shrink operation on your database will remove unused records or records to be deleted from the database to free up disk space and stay under any database file size limits. Displaced records will increase the size of the database file even if no actual data exists for these records. Both Compact and Repair, in addition, to Shrink, are not features that need to run more than once a year. The only time this would occur within a year is if major repairs were required on the database as directed by Microvellum Technical Support. It is recommended to back up the databases before running such operations.

Disaster Recovery

Microvellum recommends developing a Disaster Recovery Plan. With the knowledge, procedures designed, and documentation generated as discussed in this document and with other support documents, you have all the critical information available to reconstruct a portion of or your entire Engineering and Production System. Also, Data Backups are very important. You want to have a formal Backup System to capture all the data available in your company in addition to Microvellum Data as a standard practice. Backup Data is a crucial part of recovery.

Microvellum Services

There is a wide range of Microvellum Services available to accommodate the setup of Production Environments. Consultation is available to see what services would benefit you. 

Microvellum Technical Support

Microvellum Technical Support will assist in troubleshooting network issues impacting the functionality of Microvellum Software; however, Support is limited in regards to supporting or troubleshooting infrastructure issues. In cases of Limited Support, additional resources may be required or suggested not provided by Microvellum.