This provider assumes that all
INTEGER data returned by an ODBC driver is signed.
The provider examines the ODBC SQL type of the data, but the ODBC SQL type actually gives no indication of whether
INTEGER data is signed or unsigned.
The ODBC to .NET type mappings used internally for fetched data assume that all data is signed.
Thus there is the potential for overflow errors when fetching unsigned
INTEGER data, because the .NET types to which
INTEGER data is mapped are all signed.
However, across the range of databases we currently support, this problem only manifests itself in one instance, that being the SQL Server
This is the only native unsigned data type supported across the specific databases we cover.
However, as the Bridge Provider supports third-party ODBC drivers, more databases could expose this issue.
The SQL Server
TINYINT type has a range of 0 to 255.
It is returned by the provider as a .NET
System.SByte type, which has a range of ?128 to +127.
TINYINT values over 127 will not be returned correctly by the Provider.
The same general problem exists in the Multi-Tier Generic Client managed provider.
However, this provider handles
SQL_TINYINT data as a special case, so the problem with the SQL Server
TINYINT type does not arise.
If the provider detects data fetched using the
CTYPE_UNS8 transport type, it changes the mapping for
Any other type of unsigned integer data will not be handled correctly, but at present this does not arise as
TINYINT is the only unsigned native DBMS type the provider encounters across our currently supported agents.
However, as the Bridge Agents for ODBC and JDBC data sources support third-party ODBC and JDBC drivers, more databases could expose this issue.
All our Providers, both managed and unmanaged, map the ODBC
SQL_TYPE_TIMESTAMP type to the .NET
type stores times with millisecond precision, while an ODBC
SQL_C_TIMESTAMP struct can hold times accurate to nanoseconds.
A loss of precision will therefore result when fetching
timestamp data from databases which hold fractional second data to greater than millisecond precision.
values returned to an application will be rounded to the nearest millisecond.