Проблема: у меня есть большие таблицы из хранилища данных с номерами курсов, хранящимися как nvarchar(20).
За последние 50 лет все эти номера курсов были 8-значными, включая много ведущих нулей для более низких числа.
Но теперь наш облачный провайдер решил работать с 10-ди git номерами курсов. Численно эквивалентное значение с ведущими нулями НЕ признается облачным провайдером как эквивалентное. Они используют строгую строковую логику c. Но SQL Server 2008, кажется, пытается оказать мне «услугу», рассматривая строки цифр, как если бы они были числами.
Если я запрашиваю таблицу без предложений WHERE, я получаю только 8 git (8-символьные) записи.
Записи с 10-ди git (10-символьным) CourseNbr исчезли. Но если я явно запрашиваю записи WHERE (LEN ([CourseNbr]) = 10), он возвращает почти 200 пропущенных записей. Это просто кажется нестерпимым. Как я могу вести бизнес таким образом? Миграция на новый сервер SQL Server 2017. Может быть, эта аномалия исчезнет?
@@VERSION = Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
РЕДАКТИРОВАТЬ: я изменил тип хранения в моей локальной копии таблицы [CourseNbr] с nvarchar(20) на varchar(10) и теперь 10-ди git строка / числа появляются! И я могу искать записи из 10 символов / di git, и они отображаются нормально. Я ответил на свой вопрос? Почему это должно иметь значение?