risingwavelabs/risingwave · error

conversion of SQL Server money to {data_type} is not support

Error message

conversion of SQL Server money to {data_type} is not supported

What it means

SQL Server's `money` type is delivered as an i64 scaled by 10000. The connector only converts it to a RisingWave Decimal; any other target DataType is rejected rather than silently losing precision. The money-to-other-types mapping is intentionally unsupported.

Source

Thrown at src/connector/src/parser/sql_server.rs:136

fn coerce_scalar_to_target_type(scalar: ScalarImpl, target_type: &DataType) -> ScalarImpl {
    match (scalar, target_type) {
        // SQL Server validator allows integer upcast (e.g. `int` -> `BIGINT`).
        // Coerce snapshot values to the target RW type to keep validation and execution consistent.
        (ScalarImpl::Int16(v), DataType::Int32) => ScalarImpl::Int32(v as i32),
        (ScalarImpl::Int16(v), DataType::Int64) => ScalarImpl::Int64(v as i64),
        (ScalarImpl::Int32(v), DataType::Int64) => ScalarImpl::Int64(v as i64),
        // SQL Server `real` may map to `FLOAT` in RW validator.
        (ScalarImpl::Float32(v), DataType::Float64) => ScalarImpl::Float64((v.0 as f64).into()),
        (scalar, _) => scalar,
    }
}

fn try_convert_money_i64_to_type(value: i64, data_type: &DataType) -> anyhow::Result<ScalarImpl> {
    match data_type {
        DataType::Decimal => Ok(ScalarImpl::Decimal(
            Decimal::from(value) / Decimal::from_str("10000").unwrap(),
        )),
        _ => bail!("conversion of SQL Server money to {data_type} is not supported"),
    }
}

#[cfg(test)]
mod tests {
    use risingwave_common::types::F32;

    use super::*;

    #[test]
    fn test_integer_upcast_coercion() {
        let v = coerce_scalar_to_target_type(ScalarImpl::Int32(7), &DataType::Int64);
        assert_eq!(v, ScalarImpl::Int64(7));

        let v = coerce_scalar_to_target_type(ScalarImpl::Int16(7), &DataType::Int32);
        assert_eq!(v, ScalarImpl::Int32(7));

        let v = coerce_scalar_to_target_type(ScalarImpl::Int16(7), &DataType::Int64);

View on GitHub (pinned to 6469eb736d)

Solutions

1. Declare the RW column for the money source column as DECIMAL so the conversion succeeds.
2. Recreate/alter the RW table changing the column type to decimal.
3. Cast the money column on the SQL Server side (e.g. `CAST(col AS float)`) and declare the matching RW type.
4. Avoid mapping money to float/double; precision loss is why it is unsupported.

Example fix

-- before
CREATE TABLE t (amount double) FROM sql_server ...; -- money source column
-- after
CREATE TABLE t (amount decimal) FROM sql_server ...;

// Ensure any SQL Server money column maps to RW decimal before table creation:
fn money_target_ok(dt: &DataType) -> bool { matches!(dt, DataType::Decimal) }
-- Detect money columns in SQL Server via sys.columns.

fn money_target_ok(dt: &DataType) -> bool { matches!(dt, DataType::Decimal) }

match result {
    Err(e) if e.to_string().contains("money") && e.to_string().contains("not supported") => {
        // change the RW column type to decimal and recreate the table
    }
    other => other?,
}

When it happens

Trigger: `sql_server_cell_to_rw_datum` detects a money column and calls `try_convert_money_i64_to_type(value, data_type)`; the function bails whenever `data_type` is not `DataType::Decimal` (e.g. the RW column is Float64 or Varchar).

Common situations: RW table created against a SQL Server source with a money column declared as float/double; schema inference or hand-written schema chose a non-decimal type; expectation of automatic numeric coercion for money.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

• failed to convert PostgreSQL snapshot column `{name}` to {da
• failed to convert type {:?} to ScalarAdapter
• missing `hostname` in CDC properties
• missing `port` in CDC properties
• missing `username` in CDC properties

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/0b0d084c87cae373. Report an issue: GitHub.