Configuration Settings

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

Name

Source

Location

Contains

INT files

(filename.INT)

Migration Utility (or command-line migration tool) creates one INT file in the Data Directory for each migrated table

Data Directory or the location specified in the mds.ini file

General settings selected during migration and the Btrieve table structure

mds.ini file

Installation Wizard installs a sample in: <Program Files>\Mertech Data Systems\DB Drivers\Btrieve\sdk\samples

Data Directory

Location of the INT files, schema, server and database name, login information, table pre and postfix values

mds_global.ini file

Installation Wizard installs a sample in: <Program Files>\Mertech Data Systems\DB Drivers\Btrieve\bin

The drivers will search for this file on the %PATH%.

Global values like trace, lock and performance settings

INT files

An INT file contains all of the information necessary to allow the BTR2SQL driver to connect to, open, or recreate a converted SQL table. A partial INT file is shown below. General settings are listed first. These settings are based on information you select during migration. The field (FIELD_NUMBER 1..n) and index (INDEX_NUMBER 1..n) definitions follow. These definitions provide a picture of the file. At runtime the data is accessed on the server using this picture.

NOTE: The INT files can be different depending on the SQL server (and even the version of the server) chosen during migration. So it is not reliable to generate INT files for one server make/model/version and then target a different server version.

Sample INT file

CREATED Sat Apr 19 18:05:00 2014 by SQLBTR 5.1.6402.1
DRIVER_NAME SQL_BTR
SERVER_NAME GATEWAY\\sqlexpress
DATABASE_SPACE_NAME tempdb
TABLE_NAME CLASS
SCHEMA_NAME dbo
FILEGROUP_TABLE
FILEGROUP_INDEX
FILEGROUP_TEXT
LOGICAL_RECORD_LENGTH 14
PAGE_SIZE 4096
FILE_FLAGS 512
FILE_DDF_FLAGS 64
PERMANENT_INT NO
MAX_ROWS_TO_QUERY 100
LOCAL_CACHE YES
NUMBER_DF_FIELDS 11
PRIMARY_INDEX 1
TRANSLATE_OEM_TO_ANSI 0
IGNORE_NULL_VALUES 1
TRIM_STRING_FIELDS 1

FIELD_NUMBER 1
FIELD_NAME ID
FIELD_NATIVE_TYPE 15
FIELD_NATIVE_LENGTH 4
FIELD_NATIVE_OFFSET 0
FIELD_NATIVE_FLAG 0
FIELD_DEFAULT_VALUE 0
FIELD_AUTOINCREMENT_TYPE YES
FIELD_INDEX 1

FIELD_NUMBER 2
FIELD_NAME NAME
FIELD_NATIVE_TYPE 0
FIELD_NATIVE_LENGTH 7
FIELD_NATIVE_OFFSET 4
FIELD_NATIVE_FLAG 1
FIELD_INDEX 2
INDEX_NUMBER 1

INDEX_NUMBER_SEGMENTS 1
INDEX_SEGMENT_FIELD 1
INDEX_SEGMENT_FLAG 258

INDEX_NUMBER 2
INDEX_NUMBER_SEGMENTS 2
INDEX_SEGMENT_FIELD 2
INDEX_SEGMENT_CASE IGNORED
INDEX_SEGMENT_FLAG 1298
INDEX_SEGMENT_FIELD 3
INDEX_SEGMENT_CASE IGNORED
INDEX_SEGMENT_FLAG 1282

NOTE: Only modify the INT file as instructed (for example, to change the PERMANENT_INT setting). Unauthorized changes to the field or index tokens may result in unpredictable application errors.

mds.ini file

The mds.ini file contains the location of the INT files, schema, server and database name, login information, and table pre and postfix values. The Btr2SQL drivers use the mds.ini file in conjunction with the INT files at runtime. Some of the tokens in the mds.ini file are also used during migration:

One copy of the mds.ini file can be placed in each folder where the application’s data files are usually stored. The mds.ini file contains the following tokens. All the tokens are optional.

Token

Description

Allows you to

INT-Folder

Path to the INT files

Consolidate INT files in one directory

Server

The server name

Identify the target backend for a group of files rather than storing the information in each INT file or obtaining the information at runtime

Database

The database name

Identify the target backend for a group of files rather than storing the information in each INT file or obtaining the information at runtime

Schema

The schema name (not used in Oracle)

Identify the target backend for a group of files rather than storing the information in each INT file or obtaining the information at runtime

UseTrustedConnection

Rely on Windows authentication, yes or no. The default is no. (MSSQL only)

Store login information so a Login dialog box is not required

User

User name. If UseTrustedConnection is yes, the User and Password values are ignored

Store login information so a Login dialog box is not required

Password

A 128-bit encrypted value obtained with the command-line tool MdsEncryptPassword, which can be found in the bin folder of the Mertech driver installation

Store login information so a Login dialog box is not required

Table-Prefix

Text to prepend to the table name during migration

Create unique table names when migrating multiple directories with the same files names to the target server

Table-Postfix

Text to append to the table name during migration

Create unique table names when migrating multiple directories with the same files names to the target server

FilegroupTable

Filegroup for table data (MSSQL only)

Specify a filegroup for table data, indexes, or for text, ntext, image, xml, varchar(max), nvarchar(max), and varbinary(max) fields.

FilegroupIndex

Filegroup for indexes (MSSQL only)

Specify a filegroup for table data, indexes, or for text, ntext, image, xml, varchar(max), nvarchar(max), and varbinary(max) fields.

FilegroupText

Filegroup for large fields (MSSQL only)

Specify a filegroup for table data, indexes, or for text, ntext, image, xml, varchar(max), nvarchar(max), and varbinary(max) fields.

A sample mds.ini file is shown below. Entries under a specific heading (e.g., heading [SQL_BTR]) are only used for that driver (e.g., driver MS SQL). The driver’s default value is used when a value is left empty. Spaces are ignored around the equal sign. All settings and values are case insensitive. A more detailed description of each setting is provided in the next section.

Sample mds.ini file

[SQL_BTR]
INT-Folder=..\IntFiles_SQL
Server=mssql\sql2008
Database=testdb
Schema=dbo
UseTrustedConnection=no
User=mydomain\\me
Password=4c8fe10aad3
Table-Prefix=proj1\_
Table-Postfix=
FilegroupTable=TABLES
FilegroupIndex=INDEXES
FilegroupText=LOBFIELDS

[ORA_BTR]
INT-Folder=..\IntFiles_ORA
Server=orclsrv
User=me
Password=4c8fe10aad3
Table-Prefix=proj1\_
Table-Postfix=

[PGS_BTR]
INT-Folder=..\IntFiles_PGS
Server=pgsqlsrv:5432
Database=testdb
User=me
Password=4c8fe10aad3
Table-Prefix=proj1\_
Table-Postfix=

NOTE: A sample mds.ini file can be found in the installation folder (<Program Files>\Mertech Data Systems\DB Drivers\Btrieve\sdk\samples).

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.

../../_images/ConfigImg1.png

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

mds_global.ini file

While the mds.ini file controls information specific to each data folder, mds_global.ini contains settings with a broader scope. The location of the mds_global.ini file is up to you. The first mds_global.ini file found on the usual Path is used. We recommend placing the mds_global.ini file in the same location as the access dll and license (.cfg) file.

These locations are searched in order:

  • Current folder

  • Folder where the dll was loaded from

  • Folder where the exe was loaded from

  • System Path

  • Driver Installation bin folder

All mds_global.ini settings are listed in the table below. Settings are grouped by category: Tracing, Locking, Performance and Miscellaneous. The value marked with an asterisk (*) is the default.

Setting

Description

Tracing

Trace_On

Location of the debug trace file.

Specify the complete path and filename for the trace file. If the entry is empty, no tracing occurs.

Example: c:\trace\sql_btr.tra

Trace_Level

Trace output level.

Values:

  • -1: Errors only

  • 0: Basic

  • 1: Detailed, 1st level*

  • 2: Detailed, 2nd level

  • 3: Detailed, 3rd level

  • See also Runtime Driver Trace

Trace_Overwrite

Overwrite existing trace file?

If this option is no, the trace file name is augmented with a number each time so it does not overwrite previous traces.

Values: <yes, *no>

Trace_Flush

Flush each line to disk?

For speed, flushing is turned off by default and the operating system normal file caching mechanisms are used. However, if the application crashes, the last few lines of trace will not be output to the trace file. Enable flushing to get around this problem.

Values: <yes, *no>

Trace_Buffers

The Btrieve buffers to include in the trace output.

Values are:

  • sql (SQL statements, SQL statements are encrypted)

  • pb (Position Block)

  • kb (Key Buffer)

  • db (Data Buffer)

  • fb (Field Buffers)

Values can be combined, separated with a space or comma. For example to only include SQL statements and key buffer:

Trace_Buffers = sql kb

The default is to trace all buffers.

Trace_Gap_Allowed

Threshold (in seconds) for “slow” operations.

A large gap in the trace output timestamps can mean a potential performance penalty. When the driver notices such a gap, it adds a warning in the trace output (preceded by “Performance:”). A pattern of these warnings may pinpoint a bottleneck.

Default value: 0.80

Trace_Query_Times

Report time for queries?

Each Prepare and Execute of a query is reported in milliseconds when this option is turned on.

<yes, *no>

Trace_Mem_Stat

Monitor memory consumption and changes at beginning and end of each BTRV call.

This is only active at trace level 1 or above. The value is a combination of bit flags:

  • 0: (Default)

  • 1: Show current memory used. Shows “MemUsage :” in trace

  • 2: Include C Runtime information. Shows “MemState :” in trace

  • 4: Show a difference in memory consumption from one BTRV call to the next

Locking

Server_Side_Locking

Enforce Btrieve style locking ?

When Server_Side_Locking is set to yes, Btrieve style locking is enabled, and application locks are sent to the server where they are managed by the Mertech driver. This prevents other applications that go through the Mertech driver from accessing locked records. It does not prevent outside code from modifying records.

When Server_Side_Locking is set to no, locking still occurs on the client, but the lock is not sent to the server so concurrency is not supported. For a single instance of an application, the local information is enough.

NOTE:See also SQL_Locks below.

Values: <*yes, no>

SQL_Locks

Enable SQL locks?

Enabling Server_Side_Locking does not utilize SQL record locks, which means other processes may update records outside of the Btrieve application. It also means, a deadlock is possible since the server-side locks do not have a method to detect this.

Enabling SQL_Locks adds standard record locks, but requires that the Btrieve application request a transaction. If your application is guaranteed to always use transactions, it is recommended to turn off Server_Side_Locking and turn on SQL_Locks.

SQL_Locks adds overhead and thus impacts performance.

Values: <*yes, no>

Performance

Query_Threshold

Threshold (in seconds) for a “slow” query.

The driver keeps an eye out for queries that are returning slowly and flags these in the trace log. Look for “Performance:” in the trace to find them. Slow query times could indicate a problem with an index.

You have the option of adjusting the query threshold for your server network and server configuration. A negative time causes query times to not be reported at all.

Default time for being “slow” is 0.01 seconds

Use_Fast_Stat

Include the record count in the B_STAT?

The B_Stat function is used frequently by Btrieve applications after a B_Open to obtain basic file and key format information. This call includes the current record count. Obtaining the current record count in SQL is relatively slow and is not normally required by the application.

If Use_Fast_Stat is enabled, the record count is returned as Zero.

Values: <yes, *no>

Performance_Counter_Report

Location of the performance report.

Specify the complete path and filename for the performance report. The performance report includes counters and timings of each Btrieve function call made segregated by file. This can be useful in tracking down the slowest operations and may, for instance, highlight an index problem

Example: c:\trace\sql_btr.perf

Cache_GetEqual

Cache records for GetEqual and GetDirect.

Setting Cache_GetEqual to no (the default) forces a B_GET_EQUAL or B_GET_DIRECT call to always refresh the data from the SQL server, even if that particular row is already in the cache. This is useful for scenarios when a particular row is polled repeatedly for changes. Setting Cache_GetEqual to yes fetches the record from cache and may improve performance if the same record is requested multiple times.

Values: <yes, *no>

Miscellaneous

Btrieve_Version

Set the Btrieve version.

Sometimes an application checks the version of Btrieve to validate the API support or to narrow the range of tested scenarios. The Mertech driver always reports itself as version 7.94 in the B_VERSION call so some applications refuse to run.

Use this setting to override this number.

Default value: 7.94

Identifier_Case

Character Case of identifiers in SQL.

Controls how table and field names are handled. Values are:

  • Upper: Convert to upper case

  • Lower: Convert to lower case

  • Original: Maintain the original case*

PERVASIVE_DLL_NAME

Allows you to specify the name and optionally the path of the Btrieve access dll used for reading Btrieve data during migration

Default value: wbtrv32.dll

Sample mds_global.ini

Each piece is optional.

[SQL_BTR]
;Tracing
TRACE_ON=c:\trace\sql_btr.tra
TRACE_LEVEL=0
TRACE_FLUSH=no
;Locking
SERVER_SIDE_LOCKING=yes
SQL_LOCKS=no

[ORA_BTR]
;Location of the debug trace file
TRACE_ON = c:\trace\ora_btr.tra
TRACE_LEVEL = 0
TRACE_FLUSH=no
;Locking
SERVER_SIDE_LOCKING=yes
SQL_LOCKS=no

[PGS_BTR]
;Location of the debug trace file
TRACE_ON = c:\trace\pgs_btr.tra
TRACE_LEVEL = 0
TRACE_FLUSH=no
;Locking
SERVER_SIDE_LOCKING=yes
SQL_LOCKS=no

A semi-colon (;) at the beginning of the line in the mds_global.ini file indicates that line is a comment and is ignored. A setting is assigned in mds_global.ini by entering a value after the equal sign (e.g., Trace_On = c:\trace\sql_btr.tra). Spaces are ignored before and after the equal sign. Leaving a value empty means use the driver’s default value. All settings and values are case insensitive.

Entries under a specific heading (e.g., heading [SQL_BTR]) are only used for that driver (e.g., driver MS SQL).

NOTE: A sample mds_global.ini file can be found in the installation folder (<Program Files>\Mertech Data Systems\DB Drivers\Btrieve\bin)

Setting global and folder specific values programmatically

You can set global and folder specific settings programmatically thru a call to MdsSetSetting.

MdsSetSetting

The format for the call is:

MdsSetSetting(foldername, settingname, value)
  • foldername is the full or relative path to the folder where the msd.ini file would reside (for example, “c:\myapp\ver4\data\cust5”). The folder does not have to exist, it is simply the virtual location for the mds.ini file. If the setting being changed is in the mds_global.ini file, specify NULL for foldername.

  • settingname is any entry in the mds.ini file (for example, INT-Folder) or mds_global.ini file (for example (Trace_Level). Setting names are not case sensitive.

If a call to MdsSetSetting is made to enable TRACE_ON, that should be the last trace setting updated. If a trace is already active, it is stopped and a new file takes over using the latest trace settings.

  • value is the value to be assigned to the setting. If a Password value is provided and it starts with 0x, it is assumed that the password was encrypted using MdsEncryptPassword.

There is no need to specify a Section Name (for example [SQL_BTR]). The assumption is that the setting is for the current driver. All parameters are enclosed in quotes, so the value itself should never include quotes.

Examples:

// (mds.ini) Set the password for data files opened in the cust5 folder
MdsSetSetting("c:\\myapp\\ver4\data\\cust5", "Password", "0xed8ee3e72436da3169")
// (mds_global.ini) Limit buffer output in the trace to just KeyBuffers
MdsSetSetting(NULL, "Trace_Buffers", "kb")

How does MdsSetSetting work?

In the example below global memory settings are highlighted in turquoise, folder-specific settings are highlighted in gray and new or updated settings are shown in red text.

1 When the application starts:

  1. Registry values are read and stored.

Trace_On= c:\trace\sql_btr.tra, Trace_Level=0, TRACE_FLUSH=no, Server_Side_Locking=yes

b) Environment variable values are read and stored, overwriting any existing values.

Trace_On= c:\trace\sql_btr.tra,Trace_Level=1, TRACE_FLUSH=no, Server_Side_Locking=yes

c) mds_global.ini values are read and stored, overwriting any existing values.

Trace_On= c:\tracesql_btr.tra, Trace_Level=1,TRACE_FLUSH=yes, Server_Side_Locking=yes, Trace_Query_Times=yes

2 When the application calls MdsSetSetting (NULL, “Trace_Level”, “2”) to set a global value, any existing global value is overwritten.

Trace_On= c:\trace\sql_btr.tra,Trace_Level=2, TRACE_FLUSH=yes, Server_Side_Locking=yes, Trace_Query_Times=yes

3 When the application calls MdsSetSetting (“c:\myapp\ver4\data\cust5”, “Schema”,’cust5”) to set a folder‑specific setting:

a) If an mds.ini file exists in the specified directory (and the file was not already read when a create or open call was made) then the mds.ini file is read and the values are stored.

c:\myapp\ver4\data\cust5: Server=testserver, Database=testdb

  1. MdsSetSetting is run and in memory values are overwritten.

c:\myapp\ver4\data\cust5: Server=testserver, Database=testdb,Schema=cust5

The values set by MdsSetSetting remain in effect until the process stops.

NOTE: Be careful changing values for Schema, Database, Table-Prefix and Table-Postfix using MdsSetSetting since the changes affect all subsequent create and open calls for the selected directory.

NOTE: If there is an mds.ini file on disk, settings in that file are NOT changed by a call to MdsSetSetting. Values set by MdsSetSetting are not stored on disk.

Example

Below is an example using MdsSetSetting to create a virtual mds.ini file and then using these settings to create and open a new table.

// First, execute an embedded sql call to create new schema 'cust5'

// Next, create a virtual mds.ini file for 'c:\myapp\ver4\data\cust5'
MdsSetSetting("c:\myapp\ver4\data\cust5","INT_Folder","c:\myapp\ver4\data\intfiles_mssql")
MdsSetSetting("c:\myapp\ver4\data\cust5","Server","testserver")
MdsSetSetting("c:\myapp\ver4\data\cust5","Database","testdb")
MdsSetSetting("c:\myapp\ver4\data\cust5","Schema","cust5")
MdsSetSetting("c:\myapp\ver4\data\cust5","User","testuser")
MdsSetSetting("c:\myapp\ver4\data\cust5","Password","password")

// Now, create and open Person.mkd using the virtual mds.ini settings
B_CREATE      "c:\myapp\ver4\data\cust5\Person.mkd"
B_OPEN        "c:\myapp\ver4\data\cust5\Person.mkd"

The INT_Folder setting in the virtual mds.ini directs the application to “c:\myapp\ver4\data\intfiles_mssql” where the Person_mkd.int file is stored.

A sample directory structure is shown below. The cust1, cust2, and cust5 folders (shaded in gray) do not actually exist, they are virtual folders, created in memory by MdsSetSetting to contain a virtual mds.ini file. The application must include calls to MdsSetSetting to create these virtual data folders before it opens or creates any tables for these schemas on the server.

c:\myapp
  ver4
    data
        mds.ini(int-folder=.\intfiles_mssql server=testserver schema=common)
        intfiles_mssql
          person_mkd.int
        cust1
          mds.ini(int-folder=.\intfiles_mssql server=testserver schema=cust1)
        cust2
          mds.ini(int-folder=.\intfiles_mssql server=testserver schema=cust2)
        cust5
          mds.ini(int-folder=.\intfiles_mssql server=testserver schema=cust5)

MdsGetSetting

You can retrieve global and folder specific settings programmatically with a call to MdsGetSetting. The format for the call is:

MdsGetSetting(foldername, settingname, return value)

All settings in the mds_global.ini file and all settings in the mds.ini file (except Password) can be retrieved. Additionally these global settings, displayed at the top of the trace file, can be retrieved:

  • Driver_Info: for example, “SQLBTR 5.2.6900.99”

  • Driver_Location: for example, “C:\myapp\w3btrv7.dll”

  • Process_Info: for example, “C:\myapp\myapp.exe, Process ID 3628, WTS ID 0”

  • Computer_Name: for example, “mycomputer”

  • License_Info: for example, “Serial Number 2000 for 10 users registered to MY COMPANY”

  • Current_Working_Folder: for example, “C:\MyApp”

  • Ini_Location: for example, “C:\MyPath\mds_global.ini”   or  “C:\MyApp\data\mds.ini”

Precedence of configuration settings

Global settings can be set programmatically, in the mds_global.ini file, as environment variables and in the registry (HKEY_CURRENT_USER\SOFTWARE\Mertech Data Systems\DB Drivers\BTR\Driver\version). If a value is not found, the driver uses an internal default. Setting options are listed top to bottom, in descending order of precedence.

  • Runtime call to MdsSetSetting

  • INT file

  • mds.ini file

  • mds_global.ini file

  • Environment variables

  • Registry settings (HKCU then HKLM)

  • Driver defaults

Settings in the INT file override settings in the mds.ini file. This allows you to perhaps migrate one important table to another server or database. During migration, check the Get DatabaseName from Login option for all but the one table. Uncheck the option for the one table of interest. Doing so will cause the database name to be written only to the one INT file. For all but this one table, the Database setting in the mds.ini file will be used.

If the INT file and mds.ini file are both stored in the data directory, the INT-Folder setting in the mds.ini file is ignored and settings in the INT file and mds.ini file are merged. If a setting appears in both files (for example, the target back end tokens), the values in the INT file take precedence.

NOTE: Only one mds.ini file is allowed per data directory.

In the example below the mds.ini file contains INT-Folder=..\INTFILES:

C:\MyApp\Archives
  GLOBAL_DAT.int
  PROJ_DAT.int
  RESOURCE_LIB.int
  INTFILES\
    BILLING_MKD.int
    CLASS_MKD.int
    DEPT_MKD.int
    ENROLLS_MKD.int
    PERSON_MKD.int
  1999\
    mds.ini
    PERSON_MKD.int

When B_OPEN is called

The INT File read

C:\MyApp\Archives\1999\Person.mkd

C:\MyApp\Archives\1999\Person_mkd.int

C:\MyApp\Archives\1999\Billing.mkd

C:\MyApp\Archives\INTFILES\Billing_mkd.int