Move your Paradox application off the BDE without losing what it knows.

Why Paradox systems become hard to keep running

Most Paradox problems trace back to the Borland Database Engine (BDE), the data-access layer every Paradox application relies on. It predates modern Windows security, networking, and 64-bit computing.

• Installing and configuring the BDE on current versions of Windows often requires administrator rights, compatibility settings, and hand-edited configuration.
• Shared tables depend on a network control file (PDOXUSRS.NET) and lock files. A mismatched NET DIR setting or a dropped connection can lock users out or damage tables and indexes.
• Modern file-sharing behavior, such as SMB opportunistic locking and client-side caching, is a well-known cause of Paradox table and index corruption on shared drives.
• Business logic lives in ObjectPAL code attached to forms, reports, and libraries, which makes the rules hard to see and harder to test.
• Few developers still work in Paradox, so every fix depends on a shrinking pool of expertise.

What we inventory before anything moves

A Paradox application is more than its tables. Before planning the migration, we catalog every file the system uses and trace how the pieces depend on each other.

• Tables (.DB) with their primary indexes (.PX), memo and BLOB files (.MB), and secondary indexes.
• Validity checks and referential integrity stored in .VAL files, including required fields, minimums, maximums, defaults, picture formats, and table lookups.
• Forms, reports, queries, and scripts, along with the ObjectPAL methods attached to them.
• Aliases, BDE configuration, language drivers, and any password-protected tables.
• Imports, exports, and connections to spreadsheets, accounting packages, or other systems.

Getting the data out cleanly

Paradox data carries format details that a straight export can silently damage. We build repeatable extraction scripts and reconcile the results against the source instead of relying on a one-time conversion.

• Text is converted from the table's language driver code page to Unicode so accented and special characters survive.
• Number and Money fields, which Paradox stores as floating point, are mapped to exact decimal types, and any rounding differences are identified up front.
• Autoincrement keys, dates, times, and timestamps are preserved so existing record references keep working.
• Memo, formatted memo, graphic, and binary fields are extracted from .MB files into appropriate SQL Server types.
• Row counts, totals, and key relationships are reconciled between Paradox and the new database before cutover.

Choosing the target platform

The data typically moves to SQL Server or Azure SQL Database. The application layer depends on how your team works: a web application suits distributed users and remote access, while a .NET desktop application can suit heavy data-entry work that benefits from a familiar Windows interface. Reports are rebuilt in a modern reporting tool, and ObjectPAL business rules move into documented, testable code or database constraints.

Cutting over without stopping the business

Paradox systems usually cannot be switched off for weeks. We plan a staged transition: the new database is loaded and reconciled from Paradox extracts, users validate key workflows against real data, and the final cutover follows a last incremental load. The Paradox tables are then kept read-only for reference.

Related Services