I saw your reply but I didn't now what you were suggesting. Can you please explain? | [reply] |
I saw your reply but I didn't now what you were suggesting. Can you please explain
I didn't make a suggestion :)
I told you why your problem happens (Its the nature of the beast )
and how to solve it ( You need to use
db_stat
db_verify
db_dump
db_upgrade)
So when you encounter a problem after transferring a .db between machines, or upgrading ...
The solution is to use one of the utilities provided for this purpose, db_stat, db_verify, db_dump, db_upgrade, ...
| [reply] |
Ah, I see, thanks.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.
| [reply] |
