Необходимо принудительно вернуть MS SQL Server (2012) в исходное состояние при повторном запуске отредактированного сценария T-SQL. - PullRequest
Новая
       7

Необходимо принудительно вернуть MS SQL Server (2012) в исходное состояние при повторном запуске отредактированного сценария T-SQL.

0 голосов
/ 03 мая 2018

Очень часто очень незначительные изменения приводят к сбою моих сценариев T-SQL, когда повторно запускается из окна редактирования MS SQL Server 2012 (например, «SqlQuery1.txt»). К сожалению, нет никакого образца того, что (исправления) вызывает эту проблему. Справиться с этим заставил меня прыгнуть через несколько странных обручей.

Пример: я изменил ровно 1 символ в рабочем запросе (с «Set @THisColumn = 1» на «Set @ThisColumn = 1»; «H» был изменен на «h», чтобы соответствовать объявлению переменной) , При повторном запуске сценария MS SQL Server 2012 выдает мне эту ошибку: 

Msg 213, Level 16, State 1, Line 54
Column name or number of supplied values does not match table definition.

Мое исследование показывает, что это сообщение выдается, когда есть проблема со СТОЛОМ, которая должна быть невозможной в вышеупомянутом случае. Ошибка не важна, моя проблема гораздо более общая - необходимо использовать следующий неудовлетворительный «обходной путь»: *

Скопируйте (отредактированный) скрипт в новую панель редактирования («SQLQuery2.txt»). Это работает - до следующего редактирования. Который затем заставляет меня использовать другую панель редактирования («SQLQuery3.txt»). Повторите до Наусум.

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

Использование этого «обходного пути» разрушает мой ход мыслей, в то время как большое количество открытых окон «блокнота» приводит к тому, что я теряю слежку за тем, что я делал («... давайте посмотрим, сейчас это версия 13, 17, 26 или 28, это последняя «известная хорошая» версия? ...).

Я подозреваю, что SQL рассматривает каждый последующий повторный запуск как часть (продолжение) вызова FIRST этого сценария. Поэтому он пытается быть «полезным» ( не! ), «оптимизируя» запрос.
В среде разработки такая «помощь» очень преждевременна - и именно этого я НЕ хочу, чтобы это произошло. (Сначала заставьте его работать ... , затем оптимизируйте его.) Как подавить это нежелательное поведение?

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

IF OBJECT_ID( 'tempdb..#XYZ)  IS NOT NULL DROP TABLE #XYZ

и для временной процедуры: 

IF OBJECT_ID( 'tempdb..#ABCD) IS NOT NULL DROP PROCEDURE #ABCD  
GO  -- Required before defining any procedure
CREATE PROCEDURE #ABCD

Необходимость сделать это подразумевает, что моё предположение может быть верным (зачем ещё вам нужно это делать?).

Что еще нужно сделать, чтобы каждый раз, когда я нажимал кнопку «выполнить», я получал «чистый перезапуск» SQL?

Другие факторы, которые следует иметь в виду:

  • Сценарий, вызываемый из Python 3.x, периодически (и часто) запускается как пакетное / хроновое задание (то есть автоматически запланированное задача). Это означает, что любая форма ручного вмешательства (например, использование такие инструменты, как MS 2012 Management Studio и т. д.) не вариант.

  • Хранимые процедуры не разрешены, вместо этого приложение python считывает файл команд SQL, которые передаются в SQL для выполнения (фактически имитирует пользователя, который вводит эти команды в SQL приставка).

  • Наконец, скрипт также должен работать для пользователей с минимальным возможные (например, "гость") привилегии

.

...