MDS INI File¶

The mds.ini file is the primary configuration file used by the Btr2SQL drivers at runtime. It tells the driver where to find INT files, how to connect to the target database, and how to name tables during migration. The driver reads the mds.ini file in conjunction with the INT files whenever your application accesses data.

The mds.ini file is also used by the migration tools:

Migration Utility — uses the INT-Folder, Table-Prefix, and Table-Postfix tokens (see Scenarios using the GUI Migration Utility).
MDSMigrateTable and MigrateUniPaasData — use all tokens. Command-line arguments override values in the mds.ini file (see Options to migrate a multi-directory UniPaaS application).

File Placement and Inheritance¶

The mds.ini file should be placed in your data folder, alongside your INT files. It is common to have multiple mds.ini files — one per data folder — each containing settings specific to that folder.

Settings defined in a parent folder’s mds.ini are inherited by files in child folders. A child folder’s mds.ini only needs to contain the driver section header and the specific token being overridden or added — all other settings are inherited from the parent. For example, a child mds.ini might contain only [SQL_BTR] and Schema=company2 while the server, database, credentials, and all other settings come from the parent folder’s mds.ini. See Common Usage Scenarios for examples of this pattern.

File Format¶

Each mds.ini file should contain a single section header identifying the driver in use, followed by key/value settings. The available section headers are:

[SQL_BTR] — MS SQL
[ORA_BTR] — Oracle
[PGS_BTR] — PostgreSQL

Spaces around the equal sign are ignored and all settings and values are case insensitive. When a setting is omitted, the driver’s default value is used. All tokens are optional.

Token Reference¶

Token	Description
`INT-Folder`	This resets the data folder. Normally the data folder is the folder where the mds.ini file is located. This token allows you to specify a different folder for the INT files.
`Server`	The server name (and optionally port) to connect to. For PostgreSQL, the port can be appended with a colon (e.g., `pgserver:5432`). For MS SQL, use a backslash for named instances (e.g., `mssql\instance`). Defining this here avoids storing connection details in each individual INT file.
`Database`	The target database name. Like `Server`, setting this centrally in the mds.ini avoids duplicating it across INT files.
`Schema`	The target schema name. Not used in Oracle. This is especially useful in multi-company setups where each company’s tables reside under a different schema on the same database. Some customers use Table-Prefix or Table-Postfix to distinguish data by company, but this token allows you to use a different schema for each company.
`UseTrustedConnection`	Use Windows authentication instead of a username and password. Set to `yes` or `no`. The default is `no`. When set to `yes`, the `User` and `Password` values are ignored. MS SQL only.
`User`	The database login username. If `UseTrustedConnection` is set to `yes`, this value is ignored.
`Password`	An encrypted password value generated by the MdsEncryptPassword command-line tool. A new encrypted value is produced each time the tool is run, even for the same input password. See Password Encryption for details. A plain text password will not work.
`Table-Prefix`	Text to prepend to the table name during migration. For example, a prefix of `vendor1_` applied to a file named `orders` produces a table named `vendor1_orders`. This is useful when multiple sets of identically structured files need to coexist on the same server and database — commonly used to distinguish data by tenant, company, or environment.
`Table-Postfix`	Text to append to the table name during migration. For example, a postfix of `_vendor1` applied to a file named `orders` produces a table named `orders_vendor1`. Unlike a prefix, a postfix keeps the base table name at the beginning, which preserves the natural alphabetical ordering of your tables — all variants of `orders` will still sort together when browsing the database.
`FilegroupTable`	Filegroup to use for table data. See Microsoft’s documentation on filegroups for more information. MS SQL only.
`FilegroupIndex`	Filegroup to use for indexes. See Microsoft’s documentation on filegroups for more information. MS SQL only.
`FilegroupText`	Filegroup to use for large fields (text, ntext, image, xml, varchar(max), nvarchar(max), varbinary(max)). See Microsoft’s documentation on filegroups for more information. MS SQL only.

Sample mds.ini Files¶

The following examples show a typical mds.ini file for each driver. Remember that each mds.ini file should contain only one section header.

MS SQL

[SQL_BTR]
INT-Folder=..\IntFiles_SQL
Server=mssql\sql2022
Database=testdb
Schema=dbo
UseTrustedConnection=yes
User=mydomain\me
Table-Prefix=proj1_

Oracle

[ORA_BTR]
INT-Folder=..\IntFiles_ORA
Server=orclsrv
User=jane
Password=01c3f05c0ca0d7868adf16b133d8fe5ee820922805920dbeec8717cb07bc1b1c4264836c860105e717468f6191f2a814ac
Table-Prefix=proj1_

PostgreSQL

[PGS_BTR]
INT-Folder=..\IntFiles_PGS
Server=pgsqlsrv:5432
Database=testdb
User=john
Password=01c3f05c0ca0d7868adf16b133d8fe5ee820922805920dbeec8717cb07bc1b1c4264836c860105e717468f6191f2a814ac
Table-Prefix=proj1_

Note

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

Common Usage Scenarios¶

The following scenarios illustrate how parent/child mds.ini files are used in practice to manage multi-directory applications.

Scenario 1: Multi-Company with Schema Separation¶

An application accesses data for multiple companies. Each company’s files are stored in a separate subfolder beneath a common parent folder, which may also hold shared files.

The parent folder contains an mds.ini with the shared connection settings: Server, Database, User, and Password.
Each company subfolder contains its own mds.ini with only a Schema entry. Each company’s tables live under a different schema on the same database. All other settings are inherited from the parent.

Example directory layout

/data/
  mds.ini              <-- shared connection settings
  /company_a/
    mds.ini            <-- Schema=company_a
    orders.dat
    customers.dat
  /company_b/
    mds.ini            <-- Schema=company_b
    orders.dat
    customers.dat

Parent folder mds.ini (/data/mds.ini)

[PGS_BTR]
Server=pgserver
Database=appdb
User=appuser
Password=4c8fe10aad3

Company subfolder mds.ini (/data/company_a/mds.ini)

[PGS_BTR]
Schema=company_a

Scenario 2: Multi-Vendor with Table Prefixes¶

An application manages data for multiple vendors. When a new vendor is added, a template set of files is duplicated into a new vendor-specific folder. All vendor folders share the same file names and structure.

The parent folder contains an mds.ini with the shared connection settings.
Each vendor folder contains its own mds.ini with a Table-Prefix set to a unique value for that vendor — such as the vendor name or a numbered prefix. This allows identically named tables from each vendor to coexist on the same server and database.

Example directory layout

/data/
  mds.ini              <-- shared connection settings
  /vendor_42/
    mds.ini            <-- Table-Prefix=vendor_42_
    orders.dat
    inventory.dat
  /vendor_43/
    mds.ini            <-- Table-Prefix=vendor_43_
    orders.dat
    inventory.dat

Parent folder mds.ini (/data/mds.ini)

[PGS_BTR]
Server=pgserver
Database=vendordb
User=appuser
Password=4c8fe10aad3

Vendor subfolder mds.ini (/data/vendor_42/mds.ini)

[PGS_BTR]
Table-Prefix=vendor_42_