Всем привет!

Когда-то уже сталкивался с подобной проблемой и пришлось переходить на 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.

Ты уже неоднократно давал хорошие рекомендации, быть может сможешь помочь мне в топике: https://www.sql.ru/forum/1324848/delphi-10-3-rio-android-podkluchenie-k-mysql

Тут речь идет об подключении к MySQL из android устройства. Была рекомендация вполне рабочая - Datasnap, но это опять же сервер на Windows. Есть вариант использовать PHP, но вот именно как это технически организовать, не совсем ясно. Какие компоненты использовать, где сами скрипты хранить на сервере. И хранить ли их там или генерить на клиенте. Такие вот вопросы... Организационного характера.

Твой ответ является решением моей проблемы. Но как его выделить как решение? Или это может только модератор сделать?

Мне сейчас потребовалось вновь запускать хранимки в MySQL и ошибка аналогичная. Параметра у меня по умолчанию стоит Store.

Приложил скрины, как у меня настроено подключение. При выполнении хранимки - ошибка. Если просто бы выполнил одно действие, то ошибки не будет. А вот когда выполняется после сразу второе, то ошибка. На примере запускается хранимка и далее получаю ответ от неё. На MSSQL она работала правильно. И там вообще не было аналогичных проблем.

Dmitry Arefiev,

_Vasilisk_,

Извиняюсь, но не понимаю, как это может мне помочь?

Вот информация по подключению. Я выделил сообщение. Кажется в нем причина. То есть это получается проблема в настройках сервера? Что он не может обработать множественный запрос?

У тебя есть выбор:
1. Вернуться на MS SQL.
2. Послушать-таки советов и перестать использовать компоненты повторно.


Что значит использовать компонент повторно? У меня 30 хранимых процедур, 20 из которых делают вставку, апдейт и модификацию. Ты предлагаешь на каждую процедуру использовать отдельный компонент? Это же полный бред! Или же их генерить и уничтожать после каждого вызова? Это аналогичный бред. Компонент используется прекрасно повторно, в котором очищается SQL и всё. Никаких проблем нет и быть не может.

P.S.
Проблему я свою решил и связана она с со старой версией библиотеки libmysql.dll, которая была 2011 года. Скачал новую (которую нашел) от 2016 года и всё заработало. Скачать можно тут

То, что ты делаешь это бред. А отдельные компоненты с заданными в дизайн-тайм запросами
это серьёзное облегчение отладки и сопровождения.


Кроме огромного количества лишних строк кода я не вижу преимуществ, если честно. Каким образом это облегчит отладку?

Какого кода? Компоненты создаются в дизайне, мышкой. Строк - ноль. Отладка облегчается,
внезапно, устранением самой причины существования этого топика.


Ну так у меня и есть созданный в дизайне один query, который в нужные моменты принимает SQL с параметрами и выполняется. Что не так то? А в сам SQL я передаю имя процедуры и входные параметры.

Какого кода? Компоненты создаются в дизайне, мышкой. Строк - ноль. Отладка облегчается,
внезапно, устранением самой причины существования этого топика.


Вот код:




Запустил процедуру и получил значение поля MESS. Какой ещё тут другой способ может быть, мне не понятно. Использование компонента для хранимок не было сознательно.

Прав ты совершенно. Дата модуль для того и предназначен. Накидал компонентов и обращаешься к нему. На постоянной основе разумно держать только компоненты для постоянного отображения данных в гриде. А все остальные операции по вставке, модификации и удалению делать через один единственный квери. И никогда не будет путаницы, всё красиво и не захламлено. Я для себя пришел к прекрасной модели: DataModule, в которой все компоненты доступа к БД и отдельный Unit со всеми процедурами. Можно вынести в dll, тут по желанию. И всё. Интерфейс должен быть только лишь "коробкой" из которой дергаются те или иные процедуры. Никакой логики в нем описано не должно быть.