Thomas A. Lowery wrote: > > Great stuff, I've applied your patch to the attached copy.
Thank you, I like intermediate releases! > I did change the where the ado_consts, myado_types* to attributes of > the database handler, instead of package variable. I was having some > "score" problems. I already encountered problems after a reconnect to another data source. I think my $ado_type; (line 433) is still problematic. > One challenge is supporting two different values for SQL_BIT. Which > version is truly needed? Big trap! I mentioned this problem in http:[EMAIL PROTECTED]/msg00481.html See also Tim's reply: http:[EMAIL PROTECTED]/msg00482.html I still prefer SQL/CLI (#define SQL_BIT 14). If someone really needs to test against ODBC values (e.g. DBD::ODBC), your approach (separate MS namespace like SQL_BIT_MS) may help. > > Take a look ... let me know. > Are you sure that $AdoType == $ado_consts->{adArray} (line 1179) is correct? I have no example, but as I understand the docs, adArray is 'always combined with another data type constant' (I assume or'ed together). For example, if we have a type INTEGER ARRAY[] then - I guess! - ADO will return adInteger | adArray ??? Steffen
