[ic] Updating gdbm files
emailgrant at gmail.com
Tue Jan 25 15:46:47 UTC 2011
>> I have an Interchange 5.2.0 installation that has been running smoothly
>> since 2004. I'm now trying to move it to a new server, and have run into a
>> problem I haven't been able to solve.
>> The problem is that Interchange on the new system isn't always able to
>> read the old system's GDBM files. When I move the old file aside and
>> restart Interchange, a new one is created that works, but it doesn't contain
>> all the data from the old one (naturally).
>> This is made even more peculiar because I have two stores and they are
>> behaving differently. For a while, one didn't have any GDBM issues at all,
>> while the other wouldn't start up unless I recreated access.gdbm and
>> mv_metadata.gdbm (after which I was unable to log in). The first one has
>> recently started complaining about component.gdbm, which renders it unusable
>> (server error). I am not sure, but I wonder if the file becomes unreadable
>> after GDBM has tried to write to it.
>> The old server is running gdbm 1.07, which is beyond ancient. The new one
>> has 1.8.0. Also the old system is a 32 bit Linux (Fedora, I believe) and
>> the new one is 64 bit Centos. My best guess is that the difference in GDBM
>> versions is the problem.
>> I'd like to know if anyone else has seen this, and hopefully knows how to
>> fix it?
>> To stave off the obvious, the next step after getting the sites running
>> as-is, will be to upgrade Interchange. :)
> GDBM files are not compatible between 32bit and 64bit operating systems.
> Export all your tables to text files (e.g. from the administration) in
> order to get the up-to-date data in them. Copy the text files to the new
> system and remove the GDBM files on the new system. This should fix your
> problem. I also recommend to get rid of most GDBM files with using
> DatabaseAuto and managing table structures etc. outside of Interchange.
This is handy for exporting all tables to text files:
More information about the interchange-users