Database Encryption

Graham White

Hi all,


One of our clients (a bank) has requested (demanded actually) that our database is encrypted at rest.  I have searched the help on Unipaas and XPA and can’t really find an explanation of what I need to do.  Bill Bach from Goldsatar says  “Encrypting files requires the use of owner names, which often means modifying the underlying application” however I can’t find anything on this.  We currently use transactional method with Unipaas V1.9 however we are prepared to go to XPA if it is easier/better/more secure.


Your comments would be most appreciated.


Graham White | Software Developer | Graham.White@... |
EC Credit Control | |

This e-mail message and any attachments are confidential to EC Credit Control and subject to legal privilege. If you have received this e-mail in error, please advise the sender immediately and destroy the message and any attachments.  If you are not the intended recipient you are notified that any use, distribution, amendment, copying or any action taken or omitted to be taken in reliance of this message or attachments is prohibited.

Damian Plimmer <damian@...>

Hi Graham,

If I understand your query correctly you could try alt+enter on the table in the data source repository you wish and set the access key to encrypt to yes.

(available in both unipaas and xpa)

The help file has more information on this and does depend on the underlying databases security mechanisms so you may want to test before and after setting this. You could probably setup access to existing files directly from Pervasive Control Center.

From PCC you shouldn't be able to read the pervasive files after adding this key in theory. 

Hopefully helps :)

Kind Regards,


Steven Blank


You do not need to change versions of Magic to implement Btrieve Owner Names; Magic has supported owner names, aka, Access Keys, since forever.

To encrypt your application's database, login to the Studio as SUPERVISOR and create a new Secret Name in the Secret Names Repository. While Magic allows you to enter more than eight characters, Btrieve Owner Names are only allowed to be eight characters in length, so if you make the Secret Name's translation longer than eight characters, only the first eight will be significant. Use something wild for the translation, something like "Y!ntT5jB" (without the double quotes). If you really want to really knock yourself out, use something equally as wild for the Secret Name itself.

In your application's Data Sources Repository, assign the new Secret Name (NOT the translation) to each table's Access Key property. To do this, highlight the table in the list and press Alt+Enter to open the Data Source Properties dialog. On the Advanced tab, enter the Secret Name (NOT the translation) into the box labelled Access Key, change Encrypt Table to Yes, and click OK to save the change. When you move off the table to the next table in the repository, Magic will prompt "Should access to the table require an Access Key?" Click Yes. It only takes a second to add an owner name; encryption, however, will take some time, depending on the size of the file.

After you perform these steps in your development system, you'll obviously need to deploy the new ECF and user security file (where Secret Names are stored) to the customer's site, and then encrypt the customer's data files, too. In this case, I would employ one of Pervasive's Maintenance Utilities to add the owner name and encrypt the customer's data files.

In the GUI version of the Btrieve Maintenance Utility (w32maint.exe), use Options, Set - Clear Owner Name. One at a time, select a data file; under the Set Owner option, enter the secret name TRANSLATION in the New Owner box. Check "Encrypt data in file." DO NOT CHECK "Permit read-only access without an owner name." DO NOT CHECK "Long Owner Name". Click Execute. Do this for each data file.

If, instead, you use the command line version of the Btrieve Maintenance Utility (butil.exe), you can optionally feed it a text file of commands to add owner names to and encrypt all data files at once. In the text file, list each command separately as follows:

-setowner file0001.dat /OY!ntT5jB 2 <end>
-setowner file0002.dat /OY!ntT5jB 2 <end>
-setowner file0003.dat /OY!ntT5jB 2 <end>
-setowner filennnn.dat /OY!ntT5jB 2 <end>

The data files' new owner names follow the /O switch with no space between.The last argument is the "access level" argument; specifying "2" requires the owner name to be supplied for both reads AND writes, and encrypts the data.

Finally, supposing the commands file is named commands.txt, in order to execute the commands, change to the directory where the data files are stored and execute the following at the command line:

C:\>BUTIL @commands.txt output.txt

Appending a filename to the end, in this case "output.txt" redirects all command output to the so-named text file so you can review for errors after the fact.


Steve Blank

Graham White

Thanks guys for your help that answers everything.


Andreas Sedlmeier

Hi Graham,

I would have doubts if a bank would accept this as a solution. Its security by obscurity at the end and you can basically not answer any question about minimum encryption standards because its not documented and-or kept a secret.

There's however solutions which allow to add encryption at rest transparently and do not require you to change your application or database. Its stuff like following and that would comply with the standards then

There's more like that, that was just the first hit for a google search. I could imagine its pretty pricey so probably you are better off when you think about migrating away from Pervasive and chose MySQL or so, which does allow to comply with security standards, ..