Quick Start Guide

This guide walks you through migrating a Btrieve application to a SQL backend using BTR2SQL. It covers the essential steps from migration through deployment.

BTR2SQL includes a GUI Migration Utility and replacement database driver DLLs. The Migration Utility reads your existing Btrieve data files and DDFs, creates the corresponding tables and indexes on your SQL backend, and copies the data. It also generates Intermediate (INT) files that the Mertech driver uses at runtime to map Btrieve file operations to SQL.

Important

DDF files are required for migration using the GUI utility. If you do not have DDFs, contact Mertech before attempting migration. For alternative approaches, see MdsMigrateFile.

Prerequisites

Before you begin, make sure the following are in place. For full details, see Before You Begin.

  • Actian/Pervasive.SQL — A Pervasive.SQL 7.0 (or greater) engine is required to read DDFs during migration. If you are running Btrieve 6.15, obtain a later version from Actian along with the DDFCONV tool.

  • SQL Backend — One of the supported backends (MS SQL Server, Oracle, or PostgreSQL) must be installed and running, with the appropriate client software configured on the migration machine. Using MS SQL Server Developer Edition or PostgreSQLis recommended for testing.

Licensing

If you are evaluating BTR2SQL, a limited 30-day license is already installed. To request a fully functional 30-day evaluation license, contact sales@mertechdata.com with your company name and intended use.

When you purchase or receive a license, you will get a license file: sql_btr.cfg (MS SQL Server), ora_btr.cfg (Oracle), or pgs_btr.cfg (PostgreSQL). This file must be accessible on the system PATH. Place a copy in:

  • The BTR2SQL installation folder (<Program Files>\Mertech Data Systems\DB Drivers\Btrieve\bin) — required by the Migration Utility

  • Your application’s folder — required at runtime (see Step 2)

Your First Migration

Step 1 — Migrate Data to SQL

  1. Open the BTR2SQL Migration Utility from the Windows Start menu under Mertech Data Systems.

  2. Use Select Files to choose the tables to migrate. For a first migration, use Select All.

  3. Click Convert Data Files.

  4. Click OK to migrate all selected tables using default settings.

Tip

If Pervasive.SQL and the data reside on a different machine than the SQL server, run the migration on the Pervasive.SQL machine. This distributes the processing load between the two systems.

What happens during migration?

  1. An Intermediate file (.INT) is created alongside each data file. This file contains the schema information the Mertech driver needs at runtime.

  2. The corresponding table is created on the SQL backend (it may include additional columns or indexes required by the driver).

  3. The data is copied from the Btrieve file to the SQL table.

Note

If testing reveals misaligned table definitions, correct the DDFs and re-migrate the affected tables.

Step 2 — Replace Btrieve Access DLLs

Your application uses either wbtrv32.dll or w3btrv7.dll (32-bit) to access Btrieve data. For 64-bit applications, the equivalent DLLs are wbtrv64.dll and w64btrv.dll. BTR2SQL provides replacement DLLs that redirect these calls to the SQL backend. The replacement DLLs are located in:

  • 32-bit: <Program Files>\Mertech Data Systems\DB Drivers\Btrieve\deploy\<backend>\

  • 64-bit: <Program Files>\Mertech Data Systems\DB Drivers\Btrieve\deploy\<backend>\x64\

where <backend> is mssql, oracle, or pgsql. Choose the DLLs that match your application’s bitness. If you are unsure which DLL name your application uses, replace both.

Place the DLL where your application will find it first:

  1. Application directory (recommended) — place the DLL in the same folder as your application executable. This guarantees the correct version is loaded.

  2. System PATH — place the DLL in a common location such as Windows\System32.

Important

The license file (sql_btr.cfg, ora_btr.cfg, or pgs_btr.cfg) must also be found on the system PATH. We recommend placing it in the same folder as the replacement DLL.

Example: If your 32-bit application is in c:\myapp\bin and you are using Oracle, copy w3btrv7.dll and ora_btr.cfg from the deploy\oracle folder to c:\myapp\bin. For a 64-bit application, copy w64btrv.dll and ora_btr.cfg from deploy\oracle\x64 instead.

Step 3 — Test

With the data migrated and the Mertech DLL in place, your application should work without any code changes. When the application opens a Btrieve file (e.g., billing.mkd), the Mertech driver reads the corresponding INT file, connects to the SQL backend, and serves the data.

On first connection, a login dialog appears for the user to enter SQL credentials. You can store credentials in an mds.ini file to avoid this prompt in production.

You can shut down Pervasive services at this point — the application is now served entirely by the SQL backend.

Step 4 — Deploy

When deploying to end users, include these files with your application:

  • The Mertech replacement DLL — w3btrv7.dll / wbtrv32.dll (32-bit) or w64btrv.dll / wbtrv64.dll (64-bit)

  • The license file (e.g., sql_btr.cfg)

  • The .INT files generated during migration

  • An mds.ini file with connection settings

The original Btrieve data files and DDFs are not needed in the deployed environment. No registry keys or COM registration is required.

The SQL client libraries for your chosen backend must be installed on each machine running the application.

Tip

Store connection settings (server, database, schema) in the mds.ini file rather than in individual INT files. This makes it easy to change connection details without re-migrating.

Performance Tips

  • Configure production tracing rather than leaving full tracing on or disabling it entirely. See Production Tracing Configuration for a recommended low-overhead setup that captures errors without impacting performance.

  • Pre-allocate database space according to the current size of your Btrieve database if the backend supports it, leaving room for growth.

  • Set the Recovery Model to BULK LOGGED (MS SQL Server) during the initial migration for faster data loading, then switch to your preferred model.