Building DDFs for your Btrieve database can be the largest undertaking of a migation project. Without DDFs, your data will be read as a conglomeration of meaningless bytes. Validating DDF’s is a listed prerequisite rather than an optional step that you will need to perform before migration.
However, the validation of DDF’s with BTR2SQL can be quickly accomplished with the integrated DDF Validator. This feature has been created with the sole purpose to make it easy for you to verify the DDF’s prior to begining the migration process. Without it, you would be forced to manually build and correct DDF’s by searching for headers and sifting through possibly thousands of field names, data types, sizes, flags, etc. This handy feature transforms an exasperating a time consuming error-prone manual repair process in 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 to as a test. 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 enviornment 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 the instructions below.
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:\pvsw\demodata” -log DemoDataTest.xml