Determine the DLC version used to create a backup file

[Rob Fitzpatrick]

An issue crossed my desk yesterday. I was given a database backup file (made with probkup) and asked to restore it. I know that it's several years old and "probably" came from a Windows box.

Do I need to prorest it with exactly the same DLC version that was used to created it? If not, how close do I need to be (same major version, same minor version, same service pack)? And does the fact that prorest succeeds and I can open the database constitute sufficient evidence that I used the same DLC version as whoever ran the probkup? Or could there be silent corruption I can't see?

Is there a way to determine anything about the backup from its internal structure?

I ran strings on the backup file and sifted through the output. One helpful hint was a list of system tables. I found references to _Code-Feature and _Database-Feature, which means the DB was at least v10. I found _Area-Threshold, which means it was at least 10.1A. But I didn't find _UserTableStat, which was introduced in 10.1B.

So it is possible that this DB was backed up with 10.1B, and had just never had its VST schema updated in 10.1B. But given the date of the file and the probable time we upgraded to 10.1B (before my time), my best guess is that it's a 10.1A backup.

I'm just curious if anyone has had a requirement like this in the past, and has an easier way of getting the answer. This kind of sleuth work is a pain in the butt. I have easy access to many different Linux DLC versions, so trial and error is not a problem there. But on the Windows side I only have a few recent ones, so I'd rather avoid multiple ESD downloads if I can.

 

[Stefan]

I have no experience with this, but ProKB reports that minor release differences are allowed.
On the other hand, the 10.2B documentation reports that 10.1A / 10.1B (which is a minor release difference) is the breaking point between backups and restores due to the change from 32-bit database keys to 64-bit database keys:

Backup formats — Backup formats are incompatible between Release 10.1A and Release 10.1B and higher. The following restrictions exist:​

​

[TD="width: 100%"]

You cannot back up a 10.1A database with the 10.1B or higher PROBKUP.​

[/TD]

If you attempt to back up a 10.1A database with the 10.1B PROBKUP, the utility will use the 10.1A PROBKUP if it is available. The following sample output shows the results of backing up a 10.1A database with 10.1B PROBKUP:
​

[TABLE="class: table_0028com-lst2_0029, width: 334"]
[TR]
[TD]
$ probkup my_101a_db my_101a_db.bck
Database sp_101a uses 32-bit DBKEYs.
The 10.1A dbutil will be used to do the backup.
...[/TD]
[/TR]
[/TABLE]

The 10.1A utilities are found in the directory OpenEdge-install-dir/bin/101dbutils.​

​

[TD="width: 100%"]

You cannot back up a 10.1B or higher database with the 10.1A PROBKUP.​

[/TD]

​

[TD="width: 100%"]

You cannot restore a 10.1B or higher backup with the 10.1A PROREST.​

[/TD]

​

[TD="width: 100%"]

You can restore a 10.1A backup with the 10.1B or higher PROREST provided that:​

[/TD]

​

[TD="width: 100%"]

The database contains no before-image blocks​

[/TD]

​

[TD="width: 100%"]

The database contains no transaction log blocks​

[/TD]

The target database will be a database of the current release. If the target exists, and is a 10.1A database, it will be converted to 10.1C the current format as part of the PROREST restore.​

So your guess that it's a 10.1A backup would seem incorrect - although I have in all innocence restored a 10.2B database with 11.0 without prorest complaining - the database however was useless.

 

[Rob Fitzpatrick]

Thanks for your detailed response Stefan. Although I admit I still don't understand why you feel this backup file was not created with 10.1A probkup.

I am currently the in process of installing 10.1A for Windows to see if I can prorest with it. Based on the result I'll go from there.

 

[Stefan]

Thanks for your detailed response Stefan. Although I admit I still don't understand why you feel this backup file was not created with 10.1A probkup.

I read your post a bit too quickly and thought you had already restored the backup with 10.1B or higher, this would rule out 10.1A. Rereading your post I see that you have not attempted the restore yet - sorry for the confusion. If you happen to have 10.1B ready to run, you could see if it will indeed result in a 'normal' error.

Your investigation does point to a 10.1A database - on the other hand, if proutil -C updatevst has not been performed on the 10.1A database after upgrading to 10.1B (or higher) I am pretty sure that you will not get the new VSTs. A proutil -C conv1011 (and probably conv910) will add new VSTs, but since there is no conv required for 10.1A to 10.1B (or 10.1C or 10.2A or 10.2B) you 'need' to use updatevst to get the new VSTs. So missing VSTs does not necessarily indicate the version.

Why there is no prorest db -version (or something similar) or why prorest db -list -verbose does not tell the version (or at least version number) is beyond me.

 

[Rob Fitzpatrick]

Just thought I'd post the resolution to this issue for future reference.

This process was complicated somewhat in that I didn't have the media I needed. I had 10.1A media and RDBMS codes, but not Windows. I also had 10.1A for Windows, but not RDBMS codes. I tried using that anyway, given that the dev products include personal DB, but no dice. Finally I installed 10.1B RDBMS and used the 101a_dbutil in %DLC%\bin\101dbutils as Stefan suggested; that did the trick.

Following some of the steps in this article I did the following:

• prorest 10.1A DB:
  proenv> %DLC%\bin\101dbutils\101a_dbutil prorest dbname dbname.pbk
• truncate BI with 10.1A:
  proenv> %DLC%\bin\101dbutils\101a_dbutil dbname -C truncate bi
• open the DB with 10.1B:
  proenv> proserve dbname

From there I was able to dump the DB and load into a new structure on my Linux box. Happy days.

Why there is no prorest db -version (or something similar) or why prorest db -list -verbose does not tell the version (or at least version number) is beyond me.

Amen to that! In the meantime I'm going to have my Linux guys change the backup script to include the DLC version number in the backup name so I don't go through this nonsense again.