Опять про AUTOCOMMIT

[Габриэль]

Время от времени в блоге появляются жалобы на то, что при компиляции процедур с отладчиком появляется ругань на строку SET AUTOCOMMIT=0 (без дебагера копилятор не ругается). И в версии 4.50.306.1 опять то же самое. Но это я так, к слову, потому что не очень-то и мешает. У меня другие 2 вопроса (причем, глупые ):
1) Надо ли в каждой процедуре (в каждой!) перед стартом транзакции писать SET AUTOCOMMIT=0 (тип таблиц INNODB) ? Или достаточно это где-то указать 1 раз (подозреваю, что ДА).
2) Надо ли компилировать процедуры после их создания, после каждого редактирования и после копирования из файла? Что вообще дает компиляция? Процедуры используются только из программы, написанной в Visual Studio.
Спасибо за вожделенные ответы!

[Elias]

Здравстуйте. AUTOCOMMIT - переменная сессии. Ее достаточно установить один раз в соединении. И вряд ли лучший вариант устанавливать ее в рамках процедуры. Ошибку с AUTOCOMMIT при компиляции мы давно исправили.

Процедуры в MySql на самом деле не компилируются (когда то мы использовали этот термин для совместимости с другими нашими продуктами). Под "отладочной компиляцией" в dbForge Studio for MySql подразумевается вставка в код процедуры специальных выражений, которые позволяют контролировать выполнение процедуры. А "обычная компиляция", соответственно, этот код удаляет. Специально "компилировать" процедуру при создании не нужно. Но необходимо выполнять "компиляцию" после отладки или дебажной "компиляции" на серверах которые используются, конечными пользователями, потому что отладочная информация будет в них лишней (хоть и ощутимо не замедлит выполнение).

[Габриэль]

Спасибо за исчерпывающий ответ!

[Tsvetkov]

AUTOCOMMIT - переменная сессии. Ее достаточно установить один раз в соединении. И вряд ли лучший вариант устанавливать ее в рамках процедуры.

Все относительно. Надо знать как именно реализованы методы подключения того программного обеспечения которое подключается к базе. И от этого строить стратегию.

Например dbForge:
Создадим процедуру с одним запросом - SELECT CONNECTION_ID();

Запустим ее несколько раз - будем получать один и тот же CONNECTION_ID.
После сделаем из окна SQL этот же запрос - первый раз получим как у процедуры , а потом другие номера сессий.

Из этого можно сделать вывод , что процедура dbForge не закрывает соединения после себя со всеми вытекающими преимуществами и недостатками.

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

ТО Габриэль - покурите доку перл, модуля DBI, функции connect и connect_cached

[Габриэль]

ТО Габриэль - покурите доку перл, модуля DBI, функции connect и connect_cached

Спасибо!
Но я уже постиг, что можно еще проще. При работе с транзакционными таблицами MySQL не обязательно отключать AUTOCOMMIT (можно про него вообще забыть), если используешь START TRANSACTION. Потому что в любом случае COMMIT утверждает все изменения, а ROLLBACK их аннулирует, независимо от того, что по умолчанию AUTOCOMMIT включен. (Если я тут не прав, то поправьте меня!) У меня пока что во всех программах, использующих процедуры БД, дела обстоят именно так (SET AUTOCOMMIT=0|1 я не использую вообще).
З.Ы.
Я хотел уточнить лишь потому, что в некоторых СУБД, с которыми мне приходилось работать (например, DEC/Rdb), можно было при выключенном AUTOCOMMIT: AUTOCOMMIT OFF ,- даже не применять BEGIN_TRANS (применять только во вложенных транзакциях), а применять только END_TRANS или ROLL_TRANS (по-моему, так писалось в языке RDO, ведь с 80-х годов им не пользовался), после чего считалось, что начинается новая транзакция. По-моему, в Ingres и Oracle тоже есть что-то подобное. Я хотел заодно понять, нельзя ли так же и здесь. Но этот вопрос отпал, т.к. я уже давно привык тупо использовать START TRANSACTION (или подобную инструкцию в других СУБД), чтобы потом не тратить время на скрытые ошибки. И уже делаю это в MySQL.