Sharon Ben-Moshe is the founder of sqlfmt, a browser-based SQL formatter and validator with misspelled-keyword suggestions across PostgreSQL, MySQL, SQLite, SQL Server, and BigQuery.
SQL Server's “Conversion failed when converting the varchar value … to data type int” (Msg 245) means a string in your data, or your query, doesn't actually look like the number or date you're trying to convert it to.
Quick answer
SQL Server Msg 245, “Conversion failed when converting the varchar value '...' to data type int,” fires when a value being implicitly or explicitly converted doesn't actually match the target type — commonly a non-numeric string compared to an int column, a badly formatted date, or one bad row hiding inside otherwise-valid data. TRY_CONVERT and TRY_CAST isolate the offending row without erroring.
Msg 245 is SQL Server's “Conversion failed when converting the [type] value '...' to data type [type]” error — it fires whenever an implicit or explicit type conversion is attempted on a value that doesn't actually match the target type's format.
What's the difference between CONVERT and TRY_CONVERT?
CONVERT() raises error 245 and aborts the statement when a value can't convert; TRY_CONVERT() returns NULL instead of erroring, which makes it the standard tool for finding which specific row is causing a bulk conversion to fail.
Why does this error show up without me writing CONVERT or CAST?
SQL Server converts implicitly whenever it compares or combines two different types, such as an int column against a string literal in a WHERE clause — the conversion is real even though no CONVERT() appears anywhere in the query text.
Can regional settings really change whether a date converts?
Yes — SQL Server's default date parsing depends on the session's language and DATEFORMAT settings, so an ambiguous string like '01/02/2026' can parse as one date in one setting and fail entirely in another.
What's the safest date format to avoid this error?
The ISO 8601 format YYYY-MM-DD (or the full YYYY-MM-DDTHH:MM:SS for datetimes) is parsed the same way regardless of language or DATEFORMAT settings, which is why it's the recommended format for date literals in SQL Server.
Fix Google BigQuery's "Unrecognized name: column" error. Learn alias visibility rules across WHERE and QUALIFY, case sensitivity, and struct unnesting.
Fix PostgreSQL Error 57014: canceling statement due to statement_timeout. Learn how to tune query plans, configure timeouts per session, and avoid lock waits.
SQL Server's Msg 245 names the value and the target type directly, but for an implicit conversion buried inside a WHERE clause or a JOIN, it won't tell you which row triggered it — that part takes a query of your own.
Key takeaways
The error names the failing value directly for a one-off CAST or CONVERT, but for a per-row implicit conversion during a query, SQL Server won't say which row is at fault.
TRY_CONVERT() and TRY_CAST() return NULL instead of erroring on a bad value — the fastest way to find the specific row breaking a bulk conversion.
Implicit conversion often happens invisibly, e.g. comparing an int column to a string literal in a WHERE clause, with no CAST() or CONVERT() written by hand.
Regional and DATEFORMAT settings affect date parsing — a string that converts cleanly under one session setting can fail under another.
Why this happens: implicit vs explicit conversion
SQL Server converts implicitly whenever it compares or combines two different types — no CAST() or CONVERT() has to appear anywhere in the query text for the conversion, and the error, to be real.
SQL Server
-- order_id is int; '12A' is a non-numeric string literalSELECT * FROM orders WHERE order_id = '12A';-- Msg 245: Conversion failed when converting the varchar value '12A' to data type int.
Finding the bad row with TRY_CONVERT
When the failing value is hidden inside a bulk conversion — an ETL load, a report query over a text column that's supposed to be numeric — TRY_CONVERT isolates it without aborting the whole statement.
SQL Server
SELECT order_codeFROM ordersWHERE order_code IS NOT NULL AND TRY_CONVERT(int, order_code) IS NULL;-- Returns exactly the rows that would fail a real CONVERT(int, order_code)
Date conversions are the most common trigger
An ambiguous date string like '01/02/2026' parses differently depending on the session's language and DATEFORMAT settings — sometimes producing the wrong date silently, sometimes failing outright. ISO 8601 (YYYY-MM-DD) is parsed the same way regardless of those settings, which is why it's the safest literal format to write by hand.
SQL Server
SELECT CONVERT(date, '13/01/2026');-- Msg 241 or 245 depending on DATEFORMAT: not a valid date under mdySELECT CONVERT(date, '2026-01-13'); -- unambiguous, always worksSELECT CONVERT(date, '2026-01-13', 23); -- explicit ISO style code, same result
Fixing it: three approaches
Use TRY_CONVERT / TRY_CAST and handle the resulting NULLs explicitly, instead of letting the whole batch fail on one bad row.
Clean the source data — trim whitespace, strip non-numeric characters — before converting, if the bad values are a known data-quality issue rather than a one-off.
Use an explicit, unambiguous format or style code for dates rather than relying on the session's default parsing.
Related SQL Server errors
If the query fails before it even gets to a conversion, check “Invalid Object Name” and “Incorrect Syntax Near”. NULL-related comparison mistakes are covered in SQL NULL Comparison, and broader syntax gaps in SQL Server vs PostgreSQL. A conversion error is a data problem, not a syntax one, so sqlfmt can't catch the bad value itself — but it's still worth formatting and validating the surrounding query while you isolate the row with TRY_CONVERT.