Btrieve & Pervasive PSQL Migration
even when nobody knew it was there.
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.
You get the record structures worked out, the data moved into a current database, and the applications on top of it kept working. We do this for businesses in Australia, New Zealand, the UK and the US, at a fixed price.
- 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
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
You may be running Btrieve and not know it
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.
What the work actually is
Work out what each record means, 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.
Get a fixed-price scopeWhat 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
Only the Btrieve work you actually need
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 scopeWhat people ask us about Btrieve
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 your Btrieve system does
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.
