SQL ODBC silently truncating numeric data We have a middleware that replicates data from an Oracle (11g) database to a SQL Server (2012) using ODBC connection to the destination. One of the tables has a NUMBER data type on Oracle and given there is no exact equivalent on SQL Server, we have used DECIMAL (18,0) on the SQL Server side in hope of catching errors if the data actually has fractions. However we've noticed that replication works without any error while truncating the fractions from the numbers. We traced the queries coming from the middleware and there are bunch of sp_prepexec statements where parameters are defined as the target type (e.g. DECIMAL(18,0)) and values are already converted before reaching SQL server and hence no error despite having NUMERIC_ROUNDABORT ON on the SQL Server. Is this how ODBC supposed to work? Are there ways to force errors on these type of data type conversions?
If the parameter to the ODBC prepared statement is defined as decimal(18,0), that's how it's transmitted to the server.  The conversion is performed by the ODBC driver.  AFAIK the driver is not required by the standard to emit a diagnostic when dropping the fractional part on conversion to an integral type.  Presumably the user knows what he's doing.  ;-)  

I think you're mistaken, though.   From what I make of the NUMBER datatype, it's identical to SQL Server's decimal: you specify scale and precision up to a maximum of 38 digits.  How are they incompatible?  

If you really can't pass the data as a decimal type, I think I'd pass it as a varchar(30) and use a constraint on the SQL Server table to make sure it conforms.