SQL Server. Истории о данных: случай с фантомным дубликатом. Часть III
Содержание:
1. Часть I;
2. Часть II;
3.Часть III (Вы читаете данный раздел).
Меню Tools, пункт Options
Здесь важно отметить, что оператор GO так и не направляется на SQL Server. Он не относится к категории команд T-SQL.3tot оператор имеет смысл только для средства SSMS. В сущности, вместо него вы можете использовать другое значение. Если в меню Tools вы откроете пункт Options, то увидите то, что показано на скриншоте выше.
Я часто вспоминаю своего друга, поклонника телесериала Star Trek, который в качестве разделителя пакетов использует слово ENGAGE. Его сценарии выглядят занятно, но проку от них, с точки зрения других пользователей, немного. Кстати, интересная идея для розыгрыша нового администратора баз данных: установить в качестве разделителя слово SELECT и посмотреть, как он будет искать ошибку.
Повторение предложения
Важно понимать, что оператор GO реализован в среде SSMS, но не в процессоре SQL Server. Именно по этой причине мы можем добавить к предложениям число повторений (см. скриншот выше).
Обратите внимание: система intellisense не понимает, что означает счетчик, помещенный после оператора GO. И происходит следующее: среда SSMS направляет соответствующий пакет в систему SQL Server 100 раз.
Сценарий с ошибкой
Так вот, в нашем случае проблема состоит в том, что оператор: CONNECT в режиме SQLCMD не является разделителем пакетов. Поэтому выполнение сценария, приведенного в коде выше, вызывает проблемы.
Смотрите, что здесь происходит. Оператор: CONNECT опять-таки реализован в среде SSMS, но не в SQL Server, и все эти команды считаются входящими в один пакет. Поэтому конечный результат состоит в следующем: все четыре оператора INSERT выполняются на сервере ProdServer.
Мне такое поведение представляется странным. Как утверждается в статье Википедии «Принцип наименьшего удивления» (Principle of Least Astonishment), если необходимая функция обладает высоким «фактором удивления», возможно, ее необходимо спроектировать заново. Я сталкивался с такой проблемой в прошлом и написал разработчикам SQL Server, что ее необходимо решить (https://connect.microsoft.com/SQLServer/feedback/details/611144/sqlcmd-connect-to-a-different-server-should-be-an-implicit-batch-separator), но их ответ состоял в том, что решения не будет (Won't Fix). Если вы разделяете мою точку зрения, то, возможно, захотите оставить комментарий и тоже донести свою позицию до разработчиков. Но вернемся к нашему администратору. Мэри следовало бы выполнить команду как в коде ниже. В этом случае сценарий выполнялся бы в соответствии с замыслом администратора.
Правильный сценарий
Благодаря нашей статье наконец-то разобрались с фантомным дубликатом в SQL Server и теперь можете с чистой совестью приступить к организации праздника для своих детей. Если у вас нет опыта в таких вопросах, то настоятельно рекомендую заглянуть на http://pozdravrebenka.ru/ (http://pozdravrebenka.ru/menyu). Здесь вы найдете множество советов и рекомендаций, которые позволят вам организовать идеальный праздник для детей, который запомнится им на долгие годы!
1. Часть I;
2. Часть II;
3.
Меню Tools, пункт Options
Здесь важно отметить, что оператор GO так и не направляется на SQL Server. Он не относится к категории команд T-SQL.3tot оператор имеет смысл только для средства SSMS. В сущности, вместо него вы можете использовать другое значение. Если в меню Tools вы откроете пункт Options, то увидите то, что показано на скриншоте выше.
Я часто вспоминаю своего друга, поклонника телесериала Star Trek, который в качестве разделителя пакетов использует слово ENGAGE. Его сценарии выглядят занятно, но проку от них, с точки зрения других пользователей, немного. Кстати, интересная идея для розыгрыша нового администратора баз данных: установить в качестве разделителя слово SELECT и посмотреть, как он будет искать ошибку.
Повторение предложения
Важно понимать, что оператор GO реализован в среде SSMS, но не в процессоре SQL Server. Именно по этой причине мы можем добавить к предложениям число повторений (см. скриншот выше).
Обратите внимание: система intellisense не понимает, что означает счетчик, помещенный после оператора GO. И происходит следующее: среда SSMS направляет соответствующий пакет в систему SQL Server 100 раз.
Сценарий с ошибкой
Так вот, в нашем случае проблема состоит в том, что оператор: CONNECT в режиме SQLCMD не является разделителем пакетов. Поэтому выполнение сценария, приведенного в коде выше, вызывает проблемы.
Смотрите, что здесь происходит. Оператор: CONNECT опять-таки реализован в среде SSMS, но не в SQL Server, и все эти команды считаются входящими в один пакет. Поэтому конечный результат состоит в следующем: все четыре оператора INSERT выполняются на сервере ProdServer.
Мне такое поведение представляется странным. Как утверждается в статье Википедии «Принцип наименьшего удивления» (Principle of Least Astonishment), если необходимая функция обладает высоким «фактором удивления», возможно, ее необходимо спроектировать заново. Я сталкивался с такой проблемой в прошлом и написал разработчикам SQL Server, что ее необходимо решить (https://connect.microsoft.com/SQLServer/feedback/details/611144/sqlcmd-connect-to-a-different-server-should-be-an-implicit-batch-separator), но их ответ состоял в том, что решения не будет (Won't Fix). Если вы разделяете мою точку зрения, то, возможно, захотите оставить комментарий и тоже донести свою позицию до разработчиков. Но вернемся к нашему администратору. Мэри следовало бы выполнить команду как в коде ниже. В этом случае сценарий выполнялся бы в соответствии с замыслом администратора.
Правильный сценарий
Благодаря нашей статье наконец-то разобрались с фантомным дубликатом в SQL Server и теперь можете с чистой совестью приступить к организации праздника для своих детей. Если у вас нет опыта в таких вопросах, то настоятельно рекомендую заглянуть на http://pozdravrebenka.ru/ (http://pozdravrebenka.ru/menyu). Здесь вы найдете множество советов и рекомендаций, которые позволят вам организовать идеальный праздник для детей, который запомнится им на долгие годы!
