Значение не может быть нулевым. Имя параметра: reportElement при добавлении нового столбца Always Encrypted в существующую таблицу

Используя проекты базы данных Visual Studio (SSDT), я добавил новый столбец в существующую таблицу. Я использую Always Encrypted для шифрования отдельных столбцов. Когда я добавляю столбец и пытаюсь опубликовать, я получаю всплывающее окно в Visual Studio, в котором говорится: «Значение не может быть нулевым. Имя параметра: reportElement».

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

Ошибка Visual Studio

Я запустил ведение журнала daxFX и SSDT и просмотрел журналы с помощью средства просмотра событий Windows, но я просто вижу ту же ошибку «Значение не может быть нулевым. Имя параметра: ReportElement».

Вот как выглядит добавленное определение столбца.

[MyNewColumn] INT ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = [DefaultColumnEncryptionKey], ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL

Я ожидаю, что Visual Studio успешно опубликует, добавив мой новый зашифрованный столбец, допускающий значение NULL, но фактическое поведение представляет собой всплывающее окно, в котором говорится: «Значение не может быть нулевым. Имя параметра: reportElement».


person Jonathan    schedule 30.04.2019    source источник
comment
вы нашли решение для этого?   -  person Flezcano    schedule 05.12.2019


Ответы (1)


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

Решение состояло в том, чтобы просто выполнить шифрование вручную через SSMS, а затем запустить публикацию. Я не уверен, почему VS не может опубликовать изменения, ключи шифрования хранятся в локальном хранилище сертификатов, а VS работает от имени администратора, но он может не иметь доступа к ключам для шифрования данных, но SSMS может.

person user227669    schedule 10.07.2020
comment
Использовал ли ваш процесс CI/CD? В настоящее время я пытаюсь решить эту проблему, чтобы сделать разработку шифрования незаметной. - person Captain Prinny; 17.09.2020
comment
@CaptainPrinny да, хотя у нас нет непрерывного процесса с постоянным шифрованием, и мы не позволяем нашему процессу CI/CD шифровать/дешифровать данные. Серверу CI/CD нужен доступ к ключам шифрования, а мы не решались это сделать. На данный момент шифрование нового столбца/таблицы в порядке, потому что он пуст, и вы можете легко развернуть изменения, но шифрование или дешифрование существующих данных выполняется вручную. - person user227669; 25.09.2020