> > Hi, > > I hope this is the right place for this - apologies if not.
It's a good place. > Does anyone have any experience of using DBI:ODBC with a > Faircom db? I can't find anything in the faq or the archive. I haven't used/test Faircom in a long time -- and never with DBD::ODBC. > My problem is that $dbh->tables() is truncating the > tablenames to 64 characters. I've tested against a > MSSQLServer, and it returns the whole name even if it's more > than 64 chars, so I don't think the > problem is in DBI or DBD::ODBC. I don't either at this point. I did notice a #define in the sql.h #define SQL_MAX_TABLE_NAME_LEN 35 Which would lead me to believe that if it was cut off intentionally, it would be cut there, but it's not... > > It's not a problem with LongReadLen either (I don't think), because > (a) if LongTruncOk is false, $dbh->tables() will truncate > without generating an error > (b) Even if LongReadLen is set huge (e.g. 500000), it still truncates. No, it shouldn't be as that should never return a long column for the table name in the result set. > > What is strange, is that it's unlikely to be a problem with > the Faircom ODBC driver either, as if I do a "Select * from > CTSYSCAT_TABLES" (using dbi:odbc) then it returns the full names. Actually, not true. It can be a problem with the Faricom Driver and most likely is a problem. DBD::ODBC Tables() uses the Driver's implementation of SQLTables. DBD::ODBC doesn't try to determine where to select the data from, rather it depends upon the driver to implement SQLTables and return a result-set. What is most likely happening is that in Faircom's driver (or server), they have a 64 byte buffer which holds the data *or* they tell the result set that it's a 64 byte length on the return of the data on the column. I would check with Faircom. Regards, Jeff
