If a Crystal Reports report is created that accesses a DP4 database you may find that time fields are displayed incorrectly (as a rectangular box). This problem is caused by a combination of factors and there is a relatively straightforward work around. Early versions of Crystal reports were not capable of handling time fields correctly. As a work around for this problem the DP4 ODBC driver reports time fields as having a character data type when it detects a Crystal reports client (possible because Crystal makes invalid/undocumented calls into ODBC drivers). Unfortunately the latest release of Crystal Reports accesses data in a different way from earlier releases which means that this work around was not being applied consistently. The solution to this problem is to add the following line to datafit.ini in the [odbc] section (which should be created if necessary)
This will prevent the work around from being activated. The work around is in fact not necessary with version 6 of Crystal Reports, nor (we think) 5.
There is a bug in Crystal Reports version 8 whereby it requests data in a "default" format and assumes that this matches the information it read from the dictionary at the time the report was created. This is undoubtedly an error, because there is no reason why the database should not have changed in the meantime. There is nothing to prevent Crystal Reports asking for the specific format it is expecting. If it did so our work around for the old version would be harmless. As it is there is still a minor problem with pre-existing reports when the specified change is made to datafit.ini - because of the bug in Crystal Reports we will deliver time fields to it which it believes are strings. The cure for this is to select the Database Verify option in Crystal Reports. It will detect the changes, and if you uncheck the "match types" checkbox you will be able to match the old and new versions of time fields. Then time fields will be delivered as time fields and handled by Crystal as such.
A fixed version of odbclibt.dll is available if necessary which applies the work around for the old bug more consistently. This fix should only be necessary if two versions of Crystal Reports are in use on the same machine, and one is old enough to require our work around.