Deploying Your Application¶
Once migration is complete and testing has confirmed that your application works correctly against the SQL backend, the next step is packaging the runtime files, choosing a rollout approach, and preparing the target environment. This section is the starting point for deployment planning, whether you are a software vendor shipping a product or an IT team rolling out an internal application.
Use the topics below to plan your rollout:
Software Vendor vs. In-House Deployment Explains how deployment strategy changes depending on whether you ship software to customers or manage an internal application.
Runtime File Setup Lists the files required on client machines and where they should be placed.
XML Deployment for New Installations Shows how to automate first-time installations and table creation.
Login Credentials and Authentication Describes the authentication strategies available and how to choose the right one for your deployment.
Production Tracing Configuration Covers the recommended trace settings to leave in place on deployed systems.
Testing Before Deployment¶
Before deploying to production, invest time in thorough testing. BTR2SQL is designed so that most applications work without code changes, but there are areas that deserve focused attention:
Temporary files and dynamically created files — If your application creates Btrieve files at runtime (e.g., temporary work files, report scratch files, or session-specific data files), verify that these operations succeed against the SQL backend. The driver handles dynamic file creation, but the behavior may differ from the original Btrieve engine in some edge cases.
File move, rename, and delete operations — Applications that move, rename, or delete data files at runtime may need code adjustments. These operations affect both the underlying SQL table and the corresponding INT file, and their behavior under BTR2SQL may not match the original Btrieve file system semantics exactly.
File open and close patterns — Test areas of the application that open and close files frequently or that keep files open for extended periods. Connection pooling and handle management work differently with a SQL backend.
Multi-user and locking scenarios — Exercise concurrent access paths to confirm that locking behaves as expected. The driver translates Btrieve lock semantics to SQL, but some applications rely on subtle timing or ordering behavior that should be validated.
Error handling paths — Trigger error conditions (invalid data, duplicate keys, connection loss) and confirm the application handles them gracefully. SQL backends may return different error codes or messages than the Btrieve engine.
Tip
Run your full test suite — including any stress, concurrency, and edge-case tests — against the SQL backend before deploying. Issues found in development are far cheaper to resolve than issues found in production.