Building DDFs for your Btrieve database can be the largest undertaking of a migration project. Without DDFs, your data will be read as a conglomeration of meaningless bytes. Validating DDFs is a listed prerequisite rather than an optional step that you will need to perform before migration.
The validation of DDFs with BTR2SQL can be quickly accomplished with the integrated DDF Validator. This feature has been provided for you to easily verify the DDFs prior to beginning the migration process. Without it, you would be forced to manually build and correct DDFs by searching for headers and sifting through possibly thousands of field names, data types, sizes, flags, etc. This handy feature transforms a time consuming manual process to a simple and easy procedure.
In essence, the DDF Validation Tool will use a set of tests to verify that the existing definitions match the actual records in the file. Go to the BTR2SQL User’s Guide for instructions on how to install the DDF Builder.
Remember, even if your applications have contained DDFs for years, it is very possible that a bad value may have been accidentially inserted into the tables over time. What ever the cause a DDF error will cause significant problems when you attempt move the data to SQL.
To avoid migration errors, we recommend that you at begin by running the DDF Validator on a subset of the data rows as a test.
To validate only a subset of rows you would use the -max-rows parameter. An example that would only validate 10 rows from each table:
DDFValidator -dblocation “c:pvswdemodata” -log DemoDataTest.xml -max-rows 10
We have found that this additional effort is an excellent method to become familiar with the migration process and will help make the transition to another data environment as smooth as possible. If any changes are made to the DDFs, we recommend that you run the DDF Validation Tool on the affected tables.
Follow these instructions:
Command line
DDFValidator [-dblocation ] [-log ] [-table ] [-ignore ] [-?] -dblocation : The full path to the Pervasive.SQL DDFs, which define the database schema. If this is not provided, the current directory is assumed.
-log :Send the report (XML format) to the specified file. When -log is not included, the XML is send to stdout. When -log is provided, the XML is sent to the file and only the error messages display so you can see that the tool is working and not hung.
-table : By default, all tables are tested. This includes the -table parameter, which allows you to specify one or more tables to narrow the tests. Use semicolons to separate the list; or include the -table param multiple times.
-max-rows : Allows you to narrow the testing time by reducing the number of rows checked. If your table has 10 million rows, it is likely that after approximately the first million, the rest of the rows will validate the same way.
-ignore : Error codes to ignore - separated by semicolons. If you receive many of the same warning messages and you have verified that it is not a problem for your database, then you can filter it out to avoid littering the output.
Parameters with brackets [] are optional. Surround names with quotes if needed. (space in the name).
If -dblocation is left out, the DDFs are read from the current directory.
Example: Test the Pervasive.SQL Demodata database; send report to XML file:
DDFValidator -dblocation "c:pvswdemodata" -log DemoDataTest.xml