lab2lab Director uses an Oracle database to handle operational data. This currently requires Oracle 18.4 XE, which will be set up by reliance when your lab2lab system is commissioned. If you wish to use a pre-existing Oracle license, lab2lab's schema and SQL queries will operate with all current versions of Oracle.
Typically the Oracle database is hosted on the same PC which hosts the Director, but you can host it anywhere on the same network provided network connections are fast and reliable. If a site has multiple lab2lab systems, they can all use the same database. This is essential if the systems are inter-connected using building2building and have SPT Labtech’s Superconductor software to control instrument access.
The database schema includes tables for samples currently being processed as well as historical data about system performance. The contents of the tables in this schema should never need to be manually edited.
This is the full listing of all the tables in the schema.
ACTIVITY_HISTORY
ADDRESSES
ARM_SUBMISSIONS
BINS
BUFFERS
BUFFERS_HISTORY
COMMS_RETRY_HISTORY
CONFIG_DATA
DEFAULT_GENERATED_BARCODES
FAULT_HISTORY
GRAPHICAL_LAYOUT
L2L_B2B_APPLICATIONS
LAB2LAB_SCHEMA
LABSENDER_HISTORY
METHODS
METHODS_EXTERNAL
METHOD_HISTORY
SUBSYSTEMS
SW_EXCEPTION_HISTORY
SYSTEM_HISTORY
TRANSPORT_FAULT_HISTORY
VIALS
VIALS_EXTERNAL
VIAL_HISTORY
VIAL_TRANSPORT_HISTORY
To stop the database growing too big all tables with names ending in “_HISTORY” are periodically checked and any data is deleted when it is more than either 3 months or 12 months old, depending on the type of data. The tables do not increase in size as they are maintained dynamically (e.g. the VIALS tables) or only grow at a very modest rate (e.g. the SYSTEM_HISTORY table which only grows by one row per day).