Client Server Model
Connection Types Available in Omnis Studio
This page summarises the connection types available in Omnis and the Data Access Modules (DAMs) you can use. Please note that all DAMs other than DAMOMSQL, DAMSQLITE, DAMMYSQL and DAMPGSQL require the Professional Edition of Omnis Studio. The Professional Edition is also required if you want to implement a mobile app (for Android or iOS) with support for offline data storage and synchronisation.
Omnis Data Manipulation Language
Omnis datafiles are the original storage mechanism native to Omnis Studio and its predecessors. The "1" in the filename extension signifies the segment number. Where historically, files on the local filesystem were limited in size, adding additional segments (.DF2, .DF3, etc.) was a way to achieve a greater storage capacity. Originally, data was read and written to the datafile using a "Data Manipulation Language" (DML). These are a set of commands build into the Omnis programming environment.
Use of Omnis native datafiles with DML is still supported although due to limitations in scalability and concurrency, we recommend that all new users/apps consider using dedicated proprietary database systems, accessed using our object-oriented DAMs; multi-threaded components designed to provide a consistent programming interface across all database backends.
The OmnisSQL DAM is a wrapper around the Omnis DML engine, aimed at providing an object-oriented programming interface, consistent with the other DAMs. DAMOMSQL differs in that (like the DML engine) it is single-threaded however.
Historically, it was possible for multiple Omnis clients to share a common Omnis datafile using a "network share. Changes to modern operating systems and potential issues with corruption following severed network connections means that it is no longer practical to rely on shared network connections- and no longer possible on macOS which does not honour the file-level locking mechanism employed by the DML engine. More Information.
We developed the Omnis Data Bridge, primarily to work around the OSX file locking issue, but also to provide safer, cross-platform, concurrent access to shared Omnis datafiles across a TCP/IP network.
All access to the Omnis datafile(s) is handled by the ODB executable which can be running either locally or on another machine on the local area network. Provided that the ODB itself is stable, this system mitigates potential corruption arising from severed connections and/or system crashes, and also restores the locking mechanism used to handle multiple concurrent read/write operations.
Third-party access to Omnis Datafiles
We provide a read-only ODBC driver for Omnis datafiles, this allows ODBC-compliant third-party applications; such as Microsoft Query to read data from Omnis files in a SQL-standard manner, showing them as tables that use standard SQL data types. We provide separate ODBC drivers for macOS and Windows, and for Unicode and non-Unicode Omnis datafiles. (Datafiles used with Omnis Studio 5.0 and later are automatically converted to support Unicode).
Datafile Conversion and Emulation
In Omnis Studio 10.0, we introduced a conversion and emulation library designed to facilitate easy migration away from "legacy" datafiles, for developers who want to future-proof their DML-enabled Omnis applications.
The conversion phase involves a one-time read of data from the Omnis datafile which is copied to either a SQLite datafile or to a PostgreSQL database. Following conversion, the application library can be switched (using a library preference) so that its DML commands are emulated on-the-fly and execute against the nominated SQL database instead. The client library continues to execute with no changes to the Omnis code.
Following conversion to SQLite (or to PostgreSQL) it is possible to enhance the application to use the SQLITEDAM or PGSQLDAM directly if desired. For further information, please refer to technote TNSQ0037.
So called "single-tier" DAMs contain all the code they need to connect directly to the corresponding database. Where possible, we do this by linking or embedding the database-specific source code statically into the DAM. The FrontBase DAM can be obtained directly from FrontBase Inc.
Two-tier DAMs are dynamically linked against the required clientware library. This means that it is normally necessary to install additional third-party software before the DAM can be used, and in some cases; before it can be loaded.
In the case of PostgreSQL, we provide a suitable client library in the Omnis folder (libpq.dll, libpq.so or libpq.dylib in the Omnis.app/Contents/Frameworks folder). You may need to replace the client library from a PostgreSQL binary distribution if you want to make SSL-enabled connections. Please refer to technote TNSQ0031 for deails.
To make a two-tier connection to Microsoft SQL Server, a non-standard client library is required. Please refer to technote TNSQ0036.
The Omnis ODBC DAM can be thought of as a "three-tier" DAM. The DAM interfaces with an ODBC administration library which is normally present on Windows, macOS and Linux. The ODBC library loads and interfaces with a database-specific ODBC driver which may need to be obtained and installed separately. The ODBC driver can then access the target database across the TCP/IP network.
You normally need to setup an ODBC datasource name (DSN) before you can use an ODBC connection, although the ODBC DAM does support DSN-less connection strings if required.
The ODBC Bridge provides a TCP/IP bridge for the ODBC DAM in situations where an ODBC driver is not available on a particular client platform. When this feature is used, ODBC-bridging built into the ODBC DAM forwards low level ODBC commands to a Windows PC hosting the ODBC Bridge executable. The ODBC Bridge then accesses the ODBC library and ODBC driver installed on that machine to execute the ODBC commands and then return any results back to the Omnis client.
Mobile Devices & Offline Storage