2008-11-21 3 views
1

В настоящее время я использую osql с nant, вызывая командный файл с аргументами. Вот свойства, которые определены в моем NANT сценарии (значения нет, а не реальные имя пользователя/пароль):Использование osql с nant скриптами

<property name="project.config" value="debug" /> 
<property name="server" value="(local)" /> 
<property name="database" value="Test" /> 
<property name="username" value="sa" /> 
<property name="password" value="password" /> 

Я затем создать соединение Osql на основе имени пользователя/пароля:

<if test="${username==''}"> 
    <property name="osql.connection" value="-E" /> 
</if> 
<if test="${username!=''}"> 
    <property name="osql.connection" value="-U ${username} -P ${password}" /> 
</if> 

I затем передать эти значения на мой командный файл:

<exec program="setup.bat"> 
    <arg value="${server}"/> 
    <arg value="${database}" /> 
    <arg value="${osql.connection}" /> 
</exec> 

setup.bat файл использует OSQL, чтобы удалить базу данных:

osql -S %1 -d master %3 -Q "IF EXISTS (SELECT * FROM sysdatabases WHERE name = N'%2') DROP DATABASE [%2]" 

Это прекрасно работает, если я не передаю имя пользователя/пароль сценарию nant и не использую встроенную защиту («-E» для osql). Если я укажу имя пользователя/пароль, тогда сценарий nant просто приостанавливается (например, он ожидает ввода). Я знаю, что я указываю правильное имя пользователя/пароль, поскольку я могу войти в SQL Connection Manager и удалить базу данных.

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

ответ

2

Вот несколько предложений

  1. Чтобы помочь диагностировать проблему с NANT/пакетного сценария было бы полезно, чтобы эхо из полной команды Osql (из пакетного сценария), который выполняется. Это, конечно же, чтобы убедиться, что osql.connection расширяется правильно, когда предоставляется имя пользователя/пароль.
  2. Возможно, есть другие причины, по которым вы используете пакетный скрипт, к которому мы не привязаны. Однако, чтобы помочь диагностировать проблему, вы можете использовать задачу exec, непосредственно передаваемую в osql.exe в качестве программы. Опять же, это просто, чтобы вынуть пакетный скрипт, чтобы увидеть, работает ли он напрямую с помощью osql.exe. Кроме того, с этим вы сможете отследить всю командную строку перед выполнением, используя задачу echo.
  3. Для совершенно другого подхода вы можете попробовать задачу sql, которая является частью распределения NAntContrib. Много раз это делает очень приятную альтернативу osql.exe.

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

+0

Проблема заключается в файле osql, а не в exec, поскольку я запускал их отдельно и получал ту же ошибку. OSQL был отозван как osql -S (local) -d Test " -U sa -P password "-Q" ..... ", который, похоже, не работает. Я рассмотрю задачу sql. – 2008-11-21 16:14:50

0

Я думаю, вам может понадобиться поэкспериментировать с ORDER ваших параметров ... Кажется, я помню, что в прошлом укусила чувствительность OSQL к порядку параметров.

Вот и все, что у меня на данный момент ... извините.

0

Я предполагаю, что% 3 расширен только до "-U".

Вероятно, это может быть решена с помощью

SET Server=%1 
SET Database=%2 
SHIFT 
SHIFT 
osql -S %Server% ... %* -Q "...%Database%..." 

ИЛИ установите значение свойства включают двойные кавычки.

Update после комментария:

См this article о том, как удалить кавычки из переменных оболочки, и применить к 3-му параметру.

+0

Я пробовал вышеуказанные предложения (как метод SHIFT, так и двойные кавычки, и ни один из них не работал. OSQL был отозван как osql -S (local) -d Test «-U sa -P password» - Q "....." – 2008-11-21 16:13:18