In a DataFlex program, a table is made ready for use by opening it. This occurs when an Open statement is executed in your code (e.g., Open Customer). The Open statement must take the logical table name (e.g., Customer) and locate the physical table, read its meta-data and gain rights to access its data.
When the Open statement is encountered, DataFlex will look up this logical table name in a Filelist. If found, that Filelist entry will contain the information needed to access the table.
With the embedded database, the Filelist entry will point to the name of a file (e.g., Customer.dat) and that file will be found and opened. The embedded file contains the table’s data and its meta-data. The meta-data consists of column information (column names, data-type, length, etc.), index information and relationship information. The open logic will open this file and read this meta-data.
With SQL databases, the Filelist entry will point to an intermediate INT file (e.g., Customer.int). This INT file must provide the information needed to access the database server and retrieve the table’s meta-data.
See The Filelist for more information.
A Filelist entry will point to an intermediate configuration file called an INT file. When an Open command is encountered in your application, this file is read and used to create a definition of the table that DataFlex and your application will understand. When it reads the INT file it:
This DataFlex table definition represents a standard definition that allows the DataFlex language, DataFlex framework and your application to work with the database table, regardless of type and location using a common interface (API).
See Intermediate Files for INT file specifics.
DataFlex communicates with drivers via a DataFlex API. It is the driver’s responsibility to adhere to this API and use this to communicate directly with the back-end database. Internally, the DataFlex runtime uses this API to implement its database commands and to implement the DataDictionary class interface. This is the high-level interface you will usually use. In addition, the entire Database API is made available to developers through a set of commands.
See Attributes for more information.
Managed connections provide a mechanism for grouping SQL database tables that share the same server and login. Tables are grouped by assigning them the same abstract “connection id”. This id is mapped to a physical “connection string” that identifies a driver, server, and login credentials. This provides a mechanism for securely configuring your login credentials and is used to login to your server at the start of your application. Once logged in you can access any of your tables in this group (i.e., you can “open” the table).
Using managed connections makes it easy to switch database servers and databases. This capability is used during development (where you can switch between test database servers) and deployment (where you can define a connection to deployed database server).
Using managed connections also makes it easier to manage applications that need to connect to multiple database servers at the same.
The DataFlex Studio fully supports managed connections and it provides all the tools needed to create, configure and maintain managed connections.
You are strongly encouraged to always use managed connections when using the DataFlex SQL drivers.
See Using Managed Connections for a complete discussion on managed connections.
Normally a DataFlex application finds rows by relying a server-side unique index. This is required to make sure that the various finds (EQ, GT, LT) always find records in a fast and consistent order. With SQL databases using the DataFlex SQL drivers you can create “client-side” indexes that use the power of the SQL server to find data using partial indexes or no indexes at all. You can also use this to create temporary indexes at runtime. See SQL Indexes for more about this.
The DataFlex SQL Drivers allow you to apply server side SQL filters (basically this adds a where clause). This is applied at runtime on a table basis (global) or at the DataDictionary object instance level. See SQL Filters for more on this.
Each table in a DataFlex application must have a unique identifier called a RowId. This can be defined by defining a unique column or columns (most often the primary key) or by defining a Recnum column. See Table Types for more about this.
Special consideration must be paid when using NULL columns and when setting column defaults in SQL tables. See NULL Values and Defaults for more about this.
String data types may have spaces padding the end of the string in DataFlex. Padding and Trimming in SQL Databases describes how padding and trimming are handled in the DataFlex SQL drivers.
The "N" prefix stands for National Language in the SQL-92 standard, and is used for representing Unicode characters. While most databases do not need the added N prefix when using Unicode data, in SQL Server you must precede all Unicode strings with a prefix N when dealing with Unicode string constants. The N Prefix in SQL includes more details about that.
In your DataFlex application character strings are encoded UTF-8 characters. The backend SQL database characters can be stored in OEM or ANSI. This can be configured so that the drivers can handle this conversion for you. This is discussed under Table Character Formats in DataFlex.