Как исправить ошибку оценки ограничения приоритета DTSX при передаче переменной в командной строке? - PullRequest
4 голосов
/ 08 октября 2008

У меня есть пакет dtsx с ограничением приоритета, который оценивает выражение и ограничение. Ограничение - «успех», а выражение - «@myVariable» == 3. myVariable - это int32, и когда он установлен в графическом интерфейсе Visual Studio, пакет работает нормально. Есть два других пути, которые проверяют, чтобы значение было 1 или 2.

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

Команда:

dtexec /F "c:myPackage.dtsx" /SET 
\Package.Variables[User::myVariable].Properties[Value];3

Ошибка:

The expression "@myVariable == 1" must evaluate to True or False.  
Change the expression to evaluate to a Boolean value.

Тот факт, что это хорошо работает с графическим интерфейсом и что документация microsofts утверждает == (интуитивно) возвращает логическое значение, меня очень смутило. Я также попытался окружить 3 двойными кавычками в моей команде без удачи, и теперь у меня нет идей.

Кто-нибудь имеет представление о том, что происходит?

Ответы [ 5 ]

3 голосов
/ 21 октября 2008

Извините, что так долго возвращался к этой теме! Но (DT_I4)@[User::myVariable] == 3 сделал свое дело. Спасибо!

2 голосов
/ 22 мая 2009

Это определенно ошибка в dtexec - у меня была похожая проблема (установка целочисленного значения с помощью команды / set в командной строке dtexec), которая далее жаловалась при выполнении пакета, что переменная (output) неверного типа при возврате из хранимой процедуры.

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

1 голос
/ 12 октября 2008

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

dtexec ... /SET \Package.Variables[User::myVariable].Value;3

Примечание. Я использую .Value вместо .Properties[Value]. .Value - официальный способ, рекомендуемый Books Online. Возможно, синтаксис .Properties[Value] также работает, но меняет тип переменной.

0 голосов
/ 07 января 2009

Похоже на ошибку в ssis, потому что значение, передаваемое вами через командную строку, не преобразуется автоматически в тип переменных конфигурации. Кажется, службы SSIS обрабатывают значения, передаваемые через строку cmd, как строки, что вызывает проблемы во время выполнения. Либо измените вашу переменную на строку и выполните сравнение с ней, либо используйте (DT_I4) для приведения выражения.

0 голосов
/ 23 декабря 2008

Это похоже на ошибку в первоначальном выпуске dtexec.exe. У меня версия 9.00.3042.00, которая похожа на SQL Server 2005 с пакетом обновления 2 (SP2), установленная в моей среде разработки. У нас есть второй тестовый компьютер, который находится на версии 9.00.1399.06. Единственное место, где я вижу этот сбой - тестовая коробка. Мой разработчик коробка бежит к завершению. Я добавил явное преобразование типов (DT_BOOL) в мою логическую переменную, которая была частью моих выражений, и ошибка исчезла.

Также вышеприведенный комментарий .Value неверен. Предполагается, что это .Properties [Value], потому что значение переменной - это просто элемент в коллекции свойств глобальной переменной. Это не синтаксис C # или VB.net. Это синтаксис служб SSIS.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...