Manually recovering a database with container fields

Discussion created by kmtenor on Mar 9, 2016
Latest reply on Mar 10, 2016 by kmtenor

We have finally identified an opportunity to fix a database that has some major corruption issues.  We have attempted all of the "simple" recoveries, and are faced with re-building using a clone, as documented here and here, to rid ourselves of some nasty phantom records that are messing with our ability to run ExecuteSQL queries.


Greg Durniak's suggestion to use Merge files as the export target seems to be a good one, and I've been able to write a script that runs through a list of tables and exports them all with minimal intervention.  When I was testing it, however, I got the dreaded "Container fields cannot be exported."  Drat.


There are only about a half-dozen container fields, so they will be easy to target.  What I'm wondering is if I can (should?) make use of FM14's "BASE64ENCODE" and companion "BASE64DECODE" functions to more easily move these container fields out and back into the database.   The idea would be to encode each container field, with its filename embedded, before starting the exports.  Then, on import, decode the encoded files back into their containers, likely through a script since we aren't supposed to "perform auto-enter functions" during the imports.


So far, the only caveat I can see is time and file size - when I encoded one field yesterday on an offline copy of the database, I ran into some indexing issues that seemed to take awhile to resolve themselves.  And, of course, encoded binaries create pretty large text fields.


So, my question is this: Does it make sense to encode, export and then decode the containers to move them more easily into the clone, or is there another, simpler/better way that I'm overlooking?