Gerry47 Ответов: 3

Как построить запрос вставки, учитывающий регистр символов?

У меня есть база данных SQL Server, где я регулярно удаляю и заменяю записи на основе определенного ключевого поля. Каждая запись в каждой таблице имеет это ключевое поле. Ключевое поле чувствительно к регистру (Collation = Latin1_General_CS_AS).

Пример: у меня есть записи в базе данных со значением ключевого поля AAA. В зависимости от таблицы может быть одна или несколько таких записей.

Я хочу загрузить новые записи со значением ключевого поля aaa.

Шаг 1-это всегда удаление всех существующих записей aaa. Это происходит потому, что количество загружаемых записей может быть больше, меньше или таким же, как и раньше. Это удаление работает в том смысле, что учитывается чувствительность к регистру и записи со значением ключевого поля AAA не удаляются.

Шаг 2 - вставить записи aaa в базу данных. Однако это не удается с сообщением о том, что поле принужден быть уникальным. Значение aaa уже присутствует Проверка базы данных показывает, что это неверно. Чувствительность к регистру не применялась.

Запрос insert строится с использованием объекта command builder.

Что я уже пробовал:

Я попытался добавить к команде insert query текст "COLLATION Latin1_General_CS_AS", но это не помогло.

Как я могу построить запрос вставки так, чтобы учитывалась чувствительность к регистру?

Спасибо за любую помощь.
Джерри

Jon McKee

Запрос и то, что это за БД, могли бы помочь. Может дать COLLATE Latin1_General_BIN а пока попробуем. Ваша проблема, вероятно, заключается в спецификаторе диапазона символов, таком как c-e, который в соответствии с правилами Latin1_General_CS_AS включает верхний регистр C и D (сортированные по алфавиту).

3 Ответов

Рейтинг:
7

Wendelius

Не уверен, правильно ли я понимаю ситуацию, но если уникальность должна быть обеспечена с помощью сравнения с учетом регистра, я бы предпочел определить эту логику в таблице. Изменение инструкции insert для правильной обработки параметров сортировки звучит рискованно.

Так почему бы не определить параметры сортировки для столбца, который определен как уникальный? Рассмотрим следующий пример, где CSData колонка использует регистр уникальность и CIData без учета регистра.

CREATE TABLE CollateTest (
   CSData nvarchar(100) COLLATE Latin1_General_CS_AS,
   CIData nvarchar(100) COLLATE Latin1_General_CI_AI
);

ALTER TABLE CollateTest 
ADD CONSTRAINT UQ_CollateTest_CSData UNIQUE (CSData);

ALTER TABLE CollateTest 
ADD CONSTRAINT UQ_CollateTest_CIData UNIQUE (CIData);


INSERT INTO CollateTest (CSData, CIData) VALUES ('AAA', 'Test1'); -- succeed
INSERT INTO CollateTest (CSData, CIData) VALUES ('AAa', 'Test2'); -- succeed
INSERT INTO CollateTest (CSData, CIData) VALUES ('AAA', 'Test3'); -- fail

INSERT INTO CollateTest (CSData, CIData) VALUES ('Test1', 'AAA'); -- succeed
INSERT INTO CollateTest (CSData, CIData) VALUES ('Test2', 'AAa'); -- fail
INSERT INTO CollateTest (CSData, CIData) VALUES ('Test3', 'AAA'); -- fail

Рейтинг:
1

Gerry47

Найти проблему.

Ситуация заключается в обновлении онлайн-базы данных с помощью измененных данных из автономной базы данных.

Для каждой таблицы интерактивной базы данных была создана таблица datatable. Эти таблицы включали онлайновые данные, и это было ошибкой, как описано ниже.

Следующим шагом было записать в эти таблицы новые записи, загруженные из автономной базы данных.

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

И в этом-то и заключалась проблема. При наличии записей в datatable с ключами, которые конфликтовали с загруженными данными (когда чувствительность к регистру не учитывалась), операция добавления записей завершилась неудачей.

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

Извините, что отнял у вас время на плохо определенную проблему.
Но спасибо за вашу щедрую помощь. Очень ценю.

Рейтинг:
0

OriginalGriff

Вам нужно посмотреть на все ваши данные: ваше ограничение не только для одного столбца, содержащего "aaa", поскольку вы заявили, что можете иметь несколько строк с 2aaa" в них - следовательно, это поле не ограничено.

Однако если вы не укажете строку первичного ключа, то вся строка должна быть отдельной: так что если вы пытаетесь вставить три строки с такими данными:

AAA 1
aaa 2
aaa 3
Все будет хорошо, но вот так:
AAA 1
aaa 2
aaa 2
Он потерпит неудачу, потому что SQL не имеет возможности проверить, о какой из двух строк "aaa" вы говорите позже.

Поэтому проверьте все данные, которые вы пытаетесь вставить, и настоятельно рассмотрите возможность добавления набора строк IDENTITY или UNIQUEIDENTIFIER в качестве первичного ключа.

Gerry47

Я попробовал идею Джона, но безуспешно. Спасибо, Джон.

Существует одна таблица из пяти, где ключевое поле является единственным ключевым полем для этой таблицы. Таким образом, для данного значения ключевого поля может существовать только одна запись.

Для тестирования я беру реальное значение 2AAFCa3af0cfb и изменяю его на 2AAFCa3af0cfbAAA для начальной загрузки данных. Это всегда срабатывает. Затем я изменяю его на 2AAFCa3af0cfbaaa. Эта загрузка также должна работать, но это не так. Если я могу решить проблему для таблицы только с одной записью на уникальное значение ключевого поля, то я верю, что она будет решена для всех таблиц.