Converting Custom Crystal Reports for Adagio

Transcription

1 Introduction This document describes the steps necessary to convert Custom Crystal Reports for Adagio RPT s to use the Adagio ODBC connection introduced with the 9.2A versions of Adagio. All reports in Adagio from 9.2A forward use Crystal 2013 and Adagio ODBC for printing and display. Custom Reports must use the Adagio ODBC connection if they are to be added to a 9.2A module s Reports Menu. These RPT s should be created with Crystal 2011/2013 although an earlier version of Crystal may work (but is unsupported). The tools described in this document were used to convert the 625+ reports in all the Adagio modules, but, other than the Quality Assurance inherent in an Adagio module release, the tool itself has not been extensively tested. This document and the associated video constitute the total documentation we will be producing. If you have a custom report that fails to convert we would be interested in looking at the problem, but we make no representation of further assistance or ongoing upgrades to these tools. In some cases it may be faster to just recreate the report using the currently available tools. You should expect to have to do at least some clean up of a report after it has been converted. At a minimum, check the report linking between data tables as the links are often lost in the conversion process. Before you get started Make sure that you have the following available or installed on your computer: 1. A copy of the data set on which the reports operate 2. A \QRASP Folder with the QRW tables for the data 3. The 9.2A modules the report needs 4. Adagio ODBC properly installed and configured Convert the data to the 9.2A version. You may want both the original data and the 9.2A version available concurrently to check your work. As always, you should run Data Integrity Checks on the data after conversion to verify that the database is clean. The Report Convertor program and associated files are in the \Softrak\System\ReportConvertor Folder that will have been created and populated by the installation of any 9.2A Adagio module. No shortcut to the EXE s mention in this document are created by the install. You should run the programs from this Folder. Configuring Adagio ODBC The report conversion process relies on Adagio ODBC working properly, and you will need to create a System DSN to connect to the data in order for the report to be converted. The System DSN must be 1 P a g e

2 created with the 32-bit ODBC administrator, as the Report Convertor is a 32-bit application. Launch the 32-bit ODBC administrator. In Windows 8.1, the fastest way is to locate the necessary program is to type odbc data into the search box. Make sure that your copy of Adagio ODBC is 9.1A (140922) or later. The steps necessary for creating a System DSN are well documented in the Adagio ODBC Help text, that can be found at \Softrak\ODBCV2\AdagioODBCV2.CHM and will not be repeated here. After creating your System DSN, you should verify its correct operation by using the DSN to load the contents of an Adagio Table into Microsoft Excel. Launch Excel and select Data From Other Sources From Microsoft Query and select the DSN you created. It should be listed as below. Choose a familiar table and some fields from the table. 2 P a g e

3 Return the data to Excel, perhaps Sorted and Filtered. If this process is successful then you can be confident your ODBC connection is correctly configured. Create the Conversion Source Folder Place all your Custom Reports, and the QRT*.QRW files necessary for the conversion in a single Folder. The QRT*.QRW files will reside in your \QRASP Folder. You can copy all the files that conform to the name QRTxxWnn.QRW where xx is the application prefix letters and nn is the table version number. Only reports built using the most recent QRT*.QRW tables will convert properly. Verify the QRT*.QRW files are available Run the program RptDictUsage.EXE against the reports you need to convert. This will list the *.QRW tables you actually need for this specific conversion job. Make sure that the required QRT*.QRW tables are available. 3 P a g e

4 If your Folder contains only those QRT*.QRW files necessary for the conversion, your display may look something like this: Convert your reports Run ReportConverter.EXE, specifying the RPT you wish to convert, or the Folder containing all the RPTs needing conversion. You will need a target Folder to hold the converted reports. 4 P a g e

5 In this example: We are converting all the RPTs in the Folder c:\!oldcrystalreports using the ODBC connection we defined earlier Adagio Company Data. The type of conversion is a Table Mapping File conversion (which is all you will need at this point). The Target Folder is C:\Softrak\Ledger\CustomReports. 5 P a g e

6 Of the two RPTs in the Folder, one converted successfully ( LedgerCRW1.rpt ) and one failed ( Report1.rpt ). The failure was caused by the AR 9.2A dictionaries not being available for the report conversion process. This report conversion will have to await the shipment of Adagio Receivables V9.2A. After conversion After converting your reports, you should open each of them in turn in Crystal 2011/2013 and, using the print preview feature, verify that the report is displaying the information you want. A common cause of the report not printing properly is that the linking between the tables has been lost or improperly converted. In this case you ll have to launch the Database Database Expert menu choice in Crystal and click on the Link tab. Link the tables as necessary for the correct generation of your report. Support Please post questions about the report conversion process on Softrak s Technical Support Forum. You may be requested to upload both the RPT and the client data necessary for the report if detailed support is necessary. Remember, it may be faster to simply redefine one or two reports than to battle with a conversion process that continuously fails. All the fields and links that were available in earlier versions of Adagio are still available in the 9.2A versions, although you may notice some minor changes in Field names in order that they conform to ODBC naming onventions. 6 P a g e