Configuration Settings¶

Configuration Files Overview¶

There are three essential files used by BTR2SQL drivers to ensure that your Btrieve application operates as expected:

Consolidating INT files on the client¶

In the scenario described under Segregating tables using a prefix or postfix (or Options to migrate a multi-directory UniPaaS application) where a similar set of data files is duplicated to multiple subfolders, the INT files in each folder would be the same. While this is not a problem, it can be desirable to consolidate the files for easier maintenance. You can use the INT-Folder setting to specify the path where a common set of INT files is stored. For example you could enter this information in the mds.ini file:

INT-Folder=..\\corporate_intfiles

Specifying the target backend¶

During the migration, the Convert Data Files dialog box displays so you can choose certain migration options. This dialog box contains three check boxes, Get Server Name from Login, Get Schema Name from Login and Get Database Name from Login.

Figure 22 Settings to save the target backend

These boxes are checked by default, meaning the driver obtains this information from the Server Login dialog box when the program is run. If these boxes are not checked, this information is written to the INT files and the driver uses the stored values at runtime.

NOTE: The Get Schema Name from Login option is not used in Oracle.

But what if you want to change one of these items later? You have to update each INT file individually. You can instead choose to store these settings in the mds.ini file. During the migration, leave these three boxes checked so the server name, database name, and schema are NOT written to the INT file and instead enter this information in the mds.ini file. For example:

Server=sqlsrv2\sql2012
Database=SQLDB
Schema=dbo

Automatic application login¶

By default, a Server Login dialog box pops up when the application starts. The user has the option to save the password and subsequently avoid the dialog box, but some ISVs prefer to not have the Server Login dialog box pop up at all.

The application may include a call to the B_SQL_LOGIN (10015) API or simply include the server login information in the mds.ini file. For example:

UseTrustedConnection=no
User=mydomain\me
Password=4c8fe10aad3

Segregating tables using a prefix or postfix¶

There are several scenarios when a developer might want to distinguish groups of tables in the target database, for instance, Accounts Receivable (AR_), Accounts Payable (AP_), and Engineering (EN_). The more often need for such a feature is when tables are duplicated into multiple subfolders, a set per company or fiscal year for instance. Usually, the DDFs for each folder would be identical – having the same list of table names. So trying to migrate these to the same database would cause a name space conflict.

To avoid the conflict in names, include either a prefix such as 1999_ or a suffix like _cust1. During the migration, the tables are created with this additional appendage so “Person” would become “1999_Person” or “Person_cust1”. For example you could enter this information in the mds.ini file:

Table-Prefix=CustA\_

Or

Table-Postfix =_CustA

NOTE: Oracle allows only 30 characters for SQL identifiers and considers all identifiers in a global namespace. Because of the global nature of the identifiers, the BTR2SQL driver creates indexes, sequences, and triggers using the table name plus a suffix (respectively: _Ixx, _Sxx, _Txx). Btrieve table names are allowed to be 20 characters. Adding the four characters for the other identifiers, is 24 characters – thus leaving only 6 characters for a prefix or a suffix string if all 20 are utilized for the table names. So be conscience of this number. As an example, using a prefix of C593_, consider a table defined in the DDFs as ALRESIDENTSERVICEPLA. The table will be created in Oracle as *C1593_ALRESIDENTSERVICEPLA *and its first index will be created as *C1593_ALRESIDENTSERVICEPLA_I01 *– a full 30 characters.

Using MS SQL Filegroups¶

The MS SQL Filegroups feature is used to group database objects and files together for allocation and administration purposes. Filegroups can be selected for tables, indexes, and text storage. The properties of all the files in a filegroup can be managed simultaneously, streamlining administration.

Filegroups also provide performance advantages. Placing data and index files on separate I/O paths means that I/O resources spent retrieving data from tables do not interfere with I/O resources searching through indexes. I/O resources spent performing updates, inserts and deletes are split between the tables and the indexes. For example you could enter this information in the mds.ini file:

FilegroupTable=TABLES
FilegroupIndex=INDEXES
FilegroupText=LOBFIELDS