Всем привет!

Когда-то уже сталкивался с подобной проблемой и пришлось переходить на ZEOS компоненты. Прошло более 5 лет и вновь пришлось столкнуться с MySQL, но теперь уже использую компоненты FireDAC и хотелось бы на них и остаться. Приложение работает с хранимыми процедурами. Пытаюсь запустить вот так:




Первый раз она отработает и всё ок, но второй запуск вернет ошибку: "Commands out of sync; you can't run this command now". Любой запуск процедуры, которая возвращает результат. Погуглил и выяснил, якобы не чистится результат предыдущего результата и с этим связана ошибка. Тогда вопрос, а как его скинуть?

Хорошо. Я думаю так будет понятнее. Это предыдущий запрос.




А прописывая всегда Close, я никогда не получу ошибку, если где-то компонент остался открытым. Так как для все подобных запросов я использую один. Которые не требуется для результатирующего постоянного набора. Проще говоря, выполнять всякие вставки, апдейты, удаления и запрос статусов я всегда делаю через один квери.

Ага, ты получишь ошибку если он уже был закрыт или даже никогда не имел result set-а.


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

Ага, ты получишь ошибку если он уже был закрыт или даже никогда не имел result set-а.


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

это, типа, новый стиль программирования? Объект перед созданием надо уничтожить?
Вы бы тогда лучше писали что-то типа


чтобы найти места, в которых вы свои датасеты не закрываете вовремя.

Это не новый стиль - это правильный стиль! И не понятна попытка умничать тут совсем не к месту, не зная даже кода, который написан перед закрытие. Форум превратился в каких-то осуждающих бабок, вместо того, чтобы ответить по теме. Вот тебе кусок из примера:

Свойство SQL - вероятно, самая важная часть TQuery. Доступ к этому свойству происходит либо через Инспектор Объектов во время конструирования проекта (design time), или программно во время выполнения программы (run time).
Интересней, конечно, получить доступ к свойству SQL во время выполнения, чтобы динамически изменять запрос. Например, если требуется выполнить три SQL запроса, то не надо размещать три компонента TQuery на форме. Вместо этого можно разместить один и просто изменять свойство SQL три раза. Наиболее эффективный, простой и мощный способ - сделать это через параметризованные запросы, которые будут объяснены в следующей части. Однако, сначала исследуем основные особенности свойства SQL, а потом рассмотрим более сложные темы, типа запросов с параметрами.

Свойство SQL имеет тип TStrings, который означает что это ряд строк, сохраняемых в списке. Список действует также, как и массив, но, фактически, это специальный класс с собственными уникальными возможностями. В следующих нескольких абзацах будут рассмотрены наиболее часто используемые свойства.

При программном использовании TQuery, рекомендуется сначала закрыть текущий запрос и очистить список строк в свойстве SQL:

Query1.Close;

Query1.SQL.Clear;

Обратите внимание, что всегда можно “безопасно” вызвать Close. Даже в том случае, если запрос уже закрыт, исключительная ситуация генерироваться не будет.

Я не знаю, какие они там получают ошибки. У меня всё прекрасно работает.

Они со своим неестественным интеллектом прогнулись под дерьмопримеры, который "везде".


Попробовал с компонентами FireDAC вот такую вещь:




И вообще никаких Close не надо. Видимо под капотом само всё происходит. И это радует.

Да, спасибо за совет. Обязательно попробую. Сейчас это актуально.

Да он какой-то обиженный. Не понятно, по какой причине прицепился к CLose и Open. Совершенно нормально и ПРАВИЛЬНО делать Close перед манипуляциями с компонентом доступа. Это рекомендация самих разработчиков. А в FireDac сделали вообще прикольно и синтаксического сахара подкинули. Теперь можно в одной строке сразу запустить запрос с параметрами, просто открыв запрос.

А можно ссылку на эту рекомендацию?

Так делают когда датасет привязан к гриду и прочей дб-авари. Но это явно не твой случай.


Да это вообще был пример. Я пробовал по-разному. Хотел избежать ошибки. Как решать проблему, с помощью компонентов, так и не понятно. Я уже давно всё переписал на прямой доступ без хранимой и забил на это. Как показывает практика - это и проще. Хранимки оправданы при крупных корпоративных решениях.

Открыть документацию по MySQL API чтобы выяснить когда такая ошибка может возникать не
предлагать? Тогда остаётся только одно: перестать-таки повторно использовать компоненты, а
для выполнения запросов использовать специальный метод TFDConneciton.


Читал документацию о том, что проблема возникает по причине того, что сервак не может отдать несколько запросов в рамках одного подключения. И там есть специальный метод IP, который сбрасывает коннект. А на стороне клиента получается надо будет передергивать коннект. Решение мягко скажем не хорошее. Тут постоянный идет выбор между MSSQL и MySQL. У меня по крайней мере. MSSQL нравится, но VPS дороговато выходит по сравнению с Linux. Поэтому и приходится использовать MySQL, но тут свои "грабли". В общем оптимальным получилось делать всё с помощью запросов из клиента.

Спасибо. На будущее буду знать. Но постараюсь обходить хранимки стороной) По крайней мере на MySQL.