Search: Advanced search
Please enter a keyword or ID
Choosing a TestTrack Database Format
Note: This information only applies to TestTrack 2012 and later.
TestTrack uses SQLite for the native backend database format. However, TestTrack projects and the server database can be stored in other RDBMS types, such as SQL Server, Oracle, or PostgreSQL.
Consider the following when choosing between database formats.
The TestTrack native database format does not require much advanced administration. Other RDBMS databases usually require some administration to optimize speed, set up backup processes, etc. If you are considering using other RDBMS database types, we recommend working with an experienced database administrator. See the database vendor documentation for best practices.
When using a TestTrack native database, the TestTrack Server automatically creates the entire database. When creating other RDBMS databases, the TestTrack Server can create all of the database tables, but the physical database must already exist. Your administrator should create the physical database so they can change the configuration settings for your environment. When using an ODBC database, you must also create an ODBC data source name (DSN) so the TestTrack Server can find the database.
TestTrack native database functionality is bundled with your TestTrack user licenses and does not require additional licenses. Licenses for other RDBMS databases are not bundled with TestTrack. If you use another RDBMS database, you may need to purchase additional database licenses.
TestTrack’s built-in reports are available regardless of the database format. TestTrack also has external reporting plug-ins that can be used to create reports using a third-party reporting tool, such as Crystal Reports. Additional reporting utilities are included with some RDBMS databases. If your company has expertise with other reporting tools or has existing non-TestTrack data in a specific RDBMS database format, this may help you choose a TestTrack database format.
In our testing, operations resulted in similar timings for RDBMS and TestTrack native database formats. We selected the TestTrack native database format in part for its quick speed.
Back up TestTrack databases on a regular basis to protect against hard drive crashes, viruses, or other corruption. All of the supported RDBMS databases can be backed up, but the processes are different. See Backing Up TestTrack Databases. For information about backing up other RDBMS databases, refer to the database vendor documentation.
For both TestTrack native databases and RDBMS databases, you can configure field names, custom fields, workflows, notification rules, and more. We recommend using the TestTrack Client to make these changes instead of making them at the database level. Do not change database tables/column names, modify column size/attributes, or make any other structural database changes. These types of changes result in errors running TestTrack.
TestTrack caches data to improve the performance of complex reports and filters. Do not perform live updates of TestTrack at the database level unless the TestTrack Server has been shut down. If you want to perform live updates to TestTrack data, use SOAP, bulk field changes, or other methods available in the TestTrack Client. See Modifying TestTrack Databases for more information.