Существует ли более простой способ устранения несоответствий параметров сортировки SQL Server / базы данных, чем изменение каждого столбца?

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я знаю, что этот вопрос задавался сто раз раньше, но я просто хотел проверить, что не было более простого решения, которое я мог бы упустить, прежде чем я пошел вперед и написал / поставил много кода для этого.

Наше программное обеспечение использует базу данных, которая изначально была разработана для SQL Server 7, и поэтому все сценарии, которые ее создают, не определяют явное сопоставление для каких-либо символьных столбцов. Вместо этого, когда база данных создается / восстанавливается в SQL Server 2000 или более поздней версии, каждый столбец наследует параметры сортировки базы данных (что происходит, SQL_Latin1_General_CP1_CI_ASпоскольку это было по умолчанию в SQL Server 7).

Теоретически, это не будет иметь большого значения, поскольку, если наша база данных создается с нуля на сервере клиента, она наследует параметры сортировки сервера клиента (что обычно является современной установкой по умолчанию Latin1_General_CP1_CI_AS), и все просто работает. Однако этот сценарий нарушается, когда они отправляют нам резервную копию базы данных, или мы отправляем им резервную копию базы данных, и либо мы, либо они получают ошибку несоответствия параметров сортировки всякий раз, когда код пытается получить доступ к временным таблицам и т. Д.

Мы пытались научить клиентов устанавливать или перестраивать свои экземпляры SQL Server для использования нашего предпочтительного сопоставления, но, конечно, это не всегда происходит, и это не всегда возможно.

Решения, которые включают в себя создание новой базы данных и копирование данных, для нас не очень практичны, нам нужна «волшебная палочка», которую мы можем махнуть действующей базе данных, чтобы исправить все столбцы на месте, не нарушая данных. Я думаю о написании утилиты для этого, но, поскольку это будет довольно большая работа, есть ли у кого-нибудь более простые предложения?

Один из вариантов - «проверить» ваш код на предмет несоответствия параметров сортировки.

Вы можете использовать специальное сопоставление "DATABASE_DEFAULT", чтобы принудительно вызывать, не зная, что такое фактическое сопоставление. Вы используете его в столбцах типа char в временных таблицах, переменных таблицы и системных таблицах, которые вам нужно использовать.

Пример:

CREATE TABLE #Currency (CCY CHAR(3))
GO
INSERT #Currency VALUES ('GBP')
INSERT #Currency VALUES ('CHF')
INSERT #Currency VALUES ('EUR')
GO
SELECT Something
FROM myTable M JOIN #Currency C ON M.CCY = C.CCY --error!
GO
-- in join too
SELECT Something
FROM myTable M JOIN #Currency C ON M.CCY = C.CCY COLLATE DATABASE_DEFAULT --no error
GO
DROP TABLE #Currency
GO


CREATE TABLE  #Currency (CCY CHAR(3) COLLATE DATABASE_DEFAULT)
GO
INSERT #Currency VALUES ('GBP')
INSERT #Currency VALUES ('CHF')
INSERT #Currency VALUES ('EUR')
GO
SELECT Something
FROM myTable M JOIN #Currency C ON M.CCY = C.CCY --no error!
GO

DROP TABLE #Currency
GO

Это также означает, что когда ваши клиенты переносят свои БД на новый виртуальный сервер SQL Server с еще одним другим сопоставлением, это тоже работает ...

Короткий ответ: это не легкий путь. У меня была такая же проблема в прошлом.

Я бы сказал, что есть две вещи: сначала, когда ваш клиент отправляет вам базу данных с неожиданным сопоставлением, установите новый экземпляр SQL с сопоставлением по умолчанию, соответствующим их БД, и работайте с ним в этом.

Во-вторых, убедитесь, что ваше приложение будет работать с другими параметрами сортировки, отличными от значений по умолчанию (поскольку они могут измениться в будущем), и будет работать правильно, если параметры сортировки на сервере SQL и в базе данных совпадают. Тогда клиенту достаточно просто установить SQL-сервер с сопоставлением, соответствующим его БД, и тогда он будет работать.

Или напишите утилиту, которая обновит все таблицы и т. Д. В вашей базе данных, как вы сказали, но это может быть больше работы, чем вы хотите.

Если все столбцы в базе данных имеют одинаковое сопоставление, то это вызовет проблемы только при выполнении запросов к базе данных (или ваше приложение чувствительно к порядку сортировки).

Неприятный момент наступает, когда вы понимаете, что соединение с временными таблицами является кросс-базой данных, как и в базе данных tempdb. Это легко отсортировать - просто убедитесь, что текстовые столбцы во временных таблицах явно созданы с помощью COLLATE database_defaultдирективы. Это означает, что столбец будет создан с сопоставлением по умолчанию для текущей базы данных вместо набора по умолчанию для базы данных tempdb (который будет таким же, как сервер по умолчанию).