Btrieve & Pervasive PSQL Migration
for businesses in Australia, New Zealand, the UK and the US.
Btrieve became Pervasive PSQL and is now Actian Zen. Underneath every rename it is the same key-indexed record engine, and it sits beneath a surprising number of systems whose owners have no idea it is there.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
Most people find out they have Btrieve when something breaks
Btrieve is rarely the system anyone bought. It is the engine underneath the system they bought, which is why it turns up in accounting packages, dealership software, medical practice systems and manufacturing applications from the late 1980s onward. We found it in a client codebase as a single file, BTRIEVE.PFI, sitting under an application nobody had associated with it.
The important thing to understand is that Btrieve is not relational. It stores fixed-length records with indexes, and the meaning of the bytes in each record lives in the application, not the database. That is why an ordinary database export does not work.
Your Btrieve project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
Recover the record layout, then the data follows
The work is establishing what the bytes in each record mean. Where a DDF file set exists it names the fields for us. Where it does not, we recover the layout from the application source and prove it by reconciling against known totals.
What you have now
- .dat or .btr data files
- Record layouts held in the application
- A DDF file set, if you are lucky
- Btrieve API calls in the source
Recover the record layout, then the data follows
The work is establishing what the bytes in each record mean. Where a DDF file set exists it names the fields for us. Where it does not, we recover the layout from the application source and prove it by reconciling against known totals.
See how a project runsWhat you end up with
- Records decoded into named columns in SQL Server or PostgreSQL
- A documented record layout, so the extraction is verifiable
- Data your reporting tools can finally read
The 5 pieces of Btrieve work we are asked for
Most engagements are some combination of these, and most start with the first.
Find the record layout
From the DDF files where they exist, and from the application source where they do not. This is the whole job and everything else follows from it.
Decode the records
Fixed-length records converted into named, typed columns, including the packed decimal and date formats of the era.
Reconcile before trusting
Control totals matched against reports the business already runs, so the extraction is proven rather than assumed.
Land it in a real database
SQL Server or PostgreSQL with relationships rebuilt, so ordinary reporting tools work for the first time.
Deal with the application above it
Btrieve usually sits under something else. Once the data is out, replacing or keeping that application becomes a separate, calmer decision.
Where you are now
It works, and nobody will touch it
- A data engine most of your team does not know exists
- Record meaning held in application code, not in the database
- Reporting tools cannot read it without a translation layer
- Renamed twice, so searching for help returns three different products
After
Supported, documented and yours
- Data in a relational database with named columns
- A written record layout that anyone can verify
- Reporting straight from the database with ordinary tools
- The option to replace the application above it on your own timing
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeBtrieve questions
How do we know if we have Btrieve?
Look for .btr or .dat files alongside the application, a BTRIEVE or W3BTRV DLL, or a Pervasive or Actian service running on the server. Most people discover it only when a supplier stops answering the phone.
Can data be extracted without the DDF files?
Yes, though it takes longer. Without DDFs the record layout has to be recovered from the application source and then proved by reconciling against totals the business already trusts. We do not hand over an extraction we cannot verify.
Is Btrieve the same as Actian Zen?
It is the same lineage. Btrieve became Pervasive PSQL and then Actian Zen. Old data files are generally still readable by the current engine, which is often the cheapest first step.
Should we upgrade to current Actian instead of migrating?
Sometimes, and it is a legitimate answer if the application above it is healthy and you only need supported infrastructure. We will tell you when that is the cheaper path.
Our accounting package uses Btrieve and the vendor is gone. Now what?
That is the most common version of this call. Get the data out and verified first. It removes the risk immediately and lets you choose a replacement package without a deadline forcing the decision.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
