asked on

Type mismatch on vartype 8209 when reading DB2 recordset in Active Server Pages

I am trying to read some data from a logical file on our AS/400 (DB2) from an ASP script.

This file (and it seems all the other files in the same library) will open - I can navigate through the file using a recordset, but whenever I attempt to use a response.write on a field, I get a "Type Mismatch" error.

I tried the same thing in Visual Basic - instead of Type Mismatch the value of the field was returned as "??????????".

When I display the VarType of the field - it is returned as "8209" - which I have discovered is some sort of 'byte array' data type.

I have tried several byte array conversion routines from various 'googled' sources but none of them work - they don't bug out but the results do not match the source data.

What is puzzling me is I can open and get values from any other file in any other library - it seems restricted to files in this one library.

The data types are character data types in the source file.

Any suggestions to how I can tackle this?

I have tried both the Client Access ODBC and IBMDA400 connection strings - both do the same thing.

aplimedia

Run the array...
Example if your array = ArrMyVars

If IsArray(ArrMyVars) Then
For i = 0 to Ubound(ArrMyVars,2)
Response.write ArrMyVars(0,i) & "<BR>"
Next
end If

aplimedia

This will give the value of the first columb.

Aplimedia

ASKER CERTIFIED SOLUTION

Member_2_276102

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

KevinGaynor

ASKER

Thanks for the information I will try the suggestions as soon as possible.

KevinGaynor

ASKER

The translation table did the trick - for reference, adding ";Translate=1;" resolved it.

It worked with the Client Access driver but not the IBMDA400.

Many thanks for the help it got us out of a spot.

Member_2_276102

Minor note... The REAL answer is not to use 65535 as the CCSID unless the data are truly binary. For character data, setting the table CCSID (and the system default) to the actual CCSID helps avoid these issues from arising in the first place. You probably aren't in a position to do anything about it at the moment; but as long as remote systems will be trying to understand what comes across a network connection, the connection should provide some assistance. Be aware that this will occur again.

Tom