Data Transfer Error Message CWBTF0105

iSeries Access for Windows data transfer function reports an error message CWBTF0105 when data is found in a host file that cannot be converted. The error message text for CWBTF0105 is: Data is stored in different formats on the system and the client. An error was detected while converting data from the system format to the client format.

This error should also include the row and column where the conversion error occurred, although some versions of IBM i Access may not have the row and column specified. There are a couple of things to keep in mind about the row and column information. The term column is used as a database term here and is equivalent to indicating a field. The error message might say that the error occurred in row 200, column 10. That means that the error occurred in the tenth field of the result set or the result set column with an ordinal value of 10. You would have to check the SELECT statement in data transfer to determine if that means the tenth column of the file. The row number might not be as straightforward as it first seems. The results of any query (whether through data transfer, ODBC, or some other means) may not return the data in arrival access (the order in which the data was originally inserted into the operating system file). Unless an order is specified, the database may return the data in any order and, in some cases, it will use an existing index and return the data in an order other than arrival access.

It is important to keep these two things in mind if you are trying to find the data in the file that is causing the problem. A technique that is most expedient is to order the data in the result set. Use the DSPPFM command to confirm the order of the data in the operating system file, and modify the data transfer request so that you are guaranteed the same order when downloading the file. Do this by adding an Order by clause to the data transfer request with "RRN(filename)" in the ORDER BY section of the data transfer details. Replace filename with the actual name of the file being downloaded. To see the first failing value through data transfer, select only the row and column with the conversion failure. It may also be helpful to see the hex value of the data.

Example

Using data transfer to download a file, QIWS/QCUSTCDT, fails with a conversion error CWBTF0105 in row 3, column 5. In the data transfer GUI, selecting Data Options shows SELECT '*'. The SELECT can be modified to select only the row that causes the error. Click on the Details button in the Data Options window. On the Select tab, find the fifth column and double-click on it to replace '*' with the column name of the fifth column. In this file, the fifth column is CITY. Then, click OK to return back to the Data Options window to type in the remaining changes to the transfer. Change the Select: value from "CITY" to "CITY, HEX(CITY), RRN(QCUSTCDT)", and set the Order by: to "RRN(QCUSTCDT)". (Do not include the quotes because they are here to make it clear what is to be entered in the text boxes in the data transfer GUI). Then, run the transfer again to determine if the row listed in the error message changed. Recall that the first time the error occurred there was no order specified. Once an order is imposed on the query, the row number may change. In this case, it did not change. To see only the row with the failure, modify the data option again. This time, impose a predicate or Where clause to the query. Add the following in the text box labelled 'Where:', "RRN(QCUSTCDT)=3". Then, run the transfer again. You see only the failing value as it was converted which will be the EBCDIC hex data in the third column and the relative row number in the source file that this data is being downloaded from. Of course the error message will have changed and will now be column 1 and row 1 that causes the error because the changes made to the query changed the result set.

One thing to keep in mind is that this error is reported only for the first incidence of a conversion failure. There are potentially many more failures in the file. If you were to eliminate the first failing row from the query, you could see if there were additional error problems in the file. In the example above, you could do that by first ordering the query by RRN and then running it to see if the row number changed. Then, modify the data options so that the predicate was "RRN(QCUSTCDT)<>3". This will return all rows except the one that had the conversion error. If you get another error with this transfer, you know that there is additional invalid data in the file (and that the row number of that data is one more than what is reported in the CWBTF0105 error because you removed one row from the result). You can continue using this process until you have found all of the invalid data in the file.