Last modified: 14:35:09 11-Mar-2015
Typically, ebase allows extensive modification on the part of an organization using this system. And it often happens that a succession of part-time DB administrators have made modification over many years.
The most frequent difficulties with ebase data migrations result from problems resulting from these poor administration situations, and to inadequate guidance provided to users by inexperienced administrators.
Sometimes large numbers of fields have been added to a single table in a situation where a linked table would have been preferred. For instance:
This sort of structure requires much more data transformation effort than the
use of single linked table that had just 1 field: mail recip date
.
We have encountered situations where 40-60 fields of this type were added to a table represented an individual. Specific programming to handle each one of those fields was required.
Because inexperienced administrators often modify ebase systems, it often happens that a field is relabeled in the ebase user interface (say on a specific form), without any effort to re-name the underlying field itself.
This can result in a lot of miscommunication and misunderstanding about project requirements, etc. And it is very painstaking work for a developer to keep track of many situations where a field with one name actually contains something different than the field name would seem to indicate.
It seems common that organizations lose, misplace, or simply stop using the documentation provided with ebase. As a result, users often end up storing data incorrectly, or improvising uses of portions of the database for a different purpose than originally intended. This sometimes happens even when the database actually provides documented mechanisms specific to the need at hand.
This situation often requires complex data clean-up before data can be moved to another system like SF.
Older versions of ebase ran on early versions of Filemaker that were prone to acquiring database corruption problems during crashes or other awkward shutdowns. And most organizations using ebase did not properly adhere to common recommendations regarding database backups and the proper steps to follow after database crashes.
The effects of FileMaker database corruption in those earlier times was often sporadic. A database might run quite well for typicaly database use, but encounter problems when corrupted data is encountered during efforts to access all data contents during a data migration project.
The effort required in these situations can not be reliably predicted. Sometimes data can be transferred to a fresh set of FileMaker database files for resolution. But it often happens that despite common recommendations, an organization using ebase will not have maintained an up-to-date set of database clones representing their current database.
Last modified: 14:35:09 11-Mar-2015