Thomas A. Lowery wrote: > > > > > BTW: It seems, that the statement handle attributes need the > > > > same mapping. > > > > > > So the Provider does not supply any information on how to support > > > data types adVarWChar and adLongVarWChar. > > > > Perhaps ADO char types already support unicode. > > I does appear that the Jet driver supports unicode, however it would
That's new in Jet 4.0 (Access 2000), see e.g.: <http://support.microsoft.com/support/kb/articles/q275/5/61.asp> > be very helpful if the Provider informed us ... <sigh> In other > words, type_info_all has no knowledge of the unicode support because > the provider does not list the data types in a call to > OpenSchema(adSchemaProviderType). It does: 130 == adWChar! However, it seems that the result of OpenSchema(adSchemaProviderType) depends on the provider, but not on the data source. I got the same results for an old Access 2.0 (< Jet 4.0) datafile format. > > Here is a beginning conversion table: > I need to create a patch for DBI to support SQL_UNKNOWN_TYPE, but > for now it's a constant. > > use constant SQL_UNKNOWN_TYPE => 0; > > $myado_types_supported = { > $ado_consts->{adArray} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adBigInt} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adBinary} => DBI::SQL_BINARY > , $ado_consts->{adBoolean} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adBSTR} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adChapter} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adChar} => DBI::SQL_CHAR > , $ado_consts->{adCurrency} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adDate} => DBI::SQL_DATE > , $ado_consts->{adDBDate} => DBI::SQL_DATE > , $ado_consts->{adDBTime} => DBI::SQL_TIMESTAMP > , $ado_consts->{adDBTimeStamp} => DBI::SQL_TIMESTAMP > , $ado_consts->{adDecimal} => DBI::SQL_DECIMAL > , $ado_consts->{adDouble} => DBI::SQL_DOUBLE > , $ado_consts->{adEmpty} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adError} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adFileTime} => DBI::SQL_TIMESTAMP > , $ado_consts->{adGUID} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adIDispatch} => SQL_UNKNOWN_TYPE > , $ado_consts->{adInteger} => DBI::SQL_INTEGER > , $ado_consts->{adIUnknown} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adLongVarBinary} => DBI::SQL_LONGVARBINARY > , $ado_consts->{adLongVarChar} => DBI::SQL_LONGVARCHAR > , $ado_consts->{adLongVarWChar} => DBI::SQL_WLONGVARCHAR > , $ado_consts->{adNumeric} => DBI::SQL_NUMERIC > , $ado_consts->{adPropVariant} => SQL_UNKNOWN_TYPE > , $ado_consts->{adSingle} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adSmallInt} => DBI::SQL_SMALLINT > , $ado_consts->{adTinyInt} => DBI::SQL_TINYINT > , $ado_consts->{adUnsignedBigInt} => SQL_UNKNOWN_TYPE > , $ado_consts->{adUnsignedInt} => SQL_UNKNOWN_TYPE > , $ado_consts->{adUnsignedSmallInt} => SQL_UNKNOWN_TYPE > , $ado_consts->{adUnsignedTinyInt} => SQL_UNKNOWN_TYPE > , $ado_consts->{adUserDefined} => SQL_UNKNOWN_TYPE > , $ado_consts->{adVarBinary} => DBI::SQL_VARBINARY > , $ado_consts->{adVarChar} => DBI::SQL_VARCHAR > , $ado_consts->{adVariant} => >SQL_UNKNOWN_TYPE > , $ado_consts->{adVarNumeric} => DBI::SQL_INTEGER > , $ado_consts->{adVarWChar} => DBI::SQL_WVARCHAR > , $ado_consts->{adWChar} => DBI::SQL_WCHAR > }; > > Changes welcomed! > The next DBI release (Tim?) may allow a more complete mapping, see: <http:[EMAIL PROTECTED]/msg00483.html> Steffen
