Unfortunately I am using one of 1&1's servers and have no access to these utilities which don't seem to be available from the DB_File module. There must be others in the same position as I am, who have no knowledge of how Berkeley DB works and who are just using DB_FIle to create hash database files. They would expect a Perl upgrade to be backwards compatible and won't understand why they can't now access their database files. I also thought that newer versions of the DB engine would also be backward compatible and did check the Oracle forum to see if there were any problems in this respect and there didn't seem to be. I did know that you can't transfer one of these database files from one computer to another but here they were on the same machine.

There is no mention of possible problems in the DB_FIle CPAN page if the DB engine is upgraded and that this needs to be checked. This Perl module is only intended to be used for the facilities provided by Berekely DB version 1x and the ActiveState distribution of their ActivePerl only links DB_FIle to version 1 of the DB engine. It's unfortunate that the version of this Perl module that is installed from CPAN can't be adjusted so that it follows this practice.

Note: The database file format has changed multiple times in Berkeley DB version 2, 3 and 4. If you cannot recreate your databases, you must dump any existing databases with either the db_dump or the db_dump185 utility that comes with Berkeley DB. Once you have rebuilt DB_File to use Berkeley DB version 2 or greater, your databases can be recreated using db_load. Refer to the Berkeley DB documentation for further details.

This Perl module is only intended to be used for the facilities provided by Berekely DB version 1x and the ActiveState distribution of their ActivePerl only links DB_FIle to version 1 of the DB engine.

How did you reach that conclusion?

For example, DB_File typically isn't available on win32 by default (since libdb isn't), this is also true for ActivePerl-5.14.2.1402-MSWin32-x86-295342

It's unfortunate that the version of this Perl module that is installed from CPAN can't be adjusted so that it follows this practice.

I've been using DB_FIle for over 10 years now. I was aware early on, from experience not intuition, that DBM files can't be ported, and found this was confirmed in one of my early books on Perl, by Martin C Brown in 2001. In that time I've run CGI scripts on various servers and never had any problems until now with DB_FIle.

I don't have administration rights on the server that's running the particular script that had this problem so I couldn't do other than accept the changes that were made. There was no mention made of a change to the version of the DB engine that was going to be used by so I couldn't possibly test what the result of the changes would be beforehand. I did check that the script would run under Perl 5.10, there was nothing in the Changelog to suggest otherwise, but this was using my local version of Perl, the one distributed by ActiveState, which sensibly used version 1 of the DB engine for its DB_File

The documentation for DB_File from which you've already quoted confirms that DB_FIle is intended to be used with version 1 of the DB engine, and while it can be tied to other versions "the interface is limited to the functionality provided by Berkeley DB 1.x". The BerkeleyDB module is the one to use if the features of later versions of the engine are required.

One question perhaps you can answer. Do the other distributions of Perl and this DB_File module come with that module linked to a particular version of the Berkeley DB engine, or is it left to the server administrator to decide which version of the DB engine he/she is going to use?