Из AdoQuery в Edit.Text

Уважаемые форумчане, помогите с проблемой, у самого уже мозг под вечер кипит((((

Значит необходимо получать данные ячеек с MSSQL через AdoQuery, НО используя Parameters.

Например для обновления записей в таблице в Adoquery.Sql пишу
Update Table1 SET Имя = :Name, Материал1 = :M1, Материал2 = :M2, where № = :ID;
После чего я могу оперировать переменными Name, M1, M2 по своему усмотрению.
Например:
"ADOQuery1.Parameters.ParamByName('M1'). Value:=StrToFloat(Form4.Item1)".

А вот как сделать чтение в переменные Name, M1, M2???
Очень давно не сталкивался с SQL запросами и маленько подзабыл...
Я предполагал, что запрос должен выглядеть как то так:
"Select :Name = Имя, :M1 = Материал1, :M2 = Материал2 from table1 where № = :ID"
Ну или как то так:
"Select Имя, Материал1, Материал2 from table1 where № = :ID Set :Name = Имя, :M1 = Материал1, :M2 = Материал2;"

Да, решение типа "Edit2.Text:=Adoquery1.FieldByName('Имя' ).AsString;" не предлагать ибо для этого нужно
выполнять операции типа:
"Adoquery1.Active:=True;
Adoquery1.Open; "
и
"Adoquery1.Active:=False;
Adoquery1.Close;" каждый раз. А это ОЧЕНЬ СИЛЬНО влияет на скорость опроса!
Нужно использовать только "AdoQuery1.ExecSQL;"

Ну или можно использовать хранимую процедуру, но опять таки синтаксис sql я подзабыл(((

Так сказать задача стоит в синхронизации записей между архивом устройства и архивом компьютера.
Вот как то так...

0

что значит

"А вот как сделать чтение в переменные Name, M1, M2???"

как присвоить переменным Name, M1, M2 какие-то значения?

кладешь TEdit для соответствующей переменной, где-нибудь кнопку "OK", которая запустить на выполнение запрос

0

Сообщение от zremas что значит как присвоить переменным Name, M1, M2 какие-то значения? кладешь TEdit для соответствующей переменной, где-нибудь кнопку "OK", которая запустить на выполнение запрос T-SQL 1 Select * from MyTable where Name = :Name and Material1 =:M1 and Materail2 =:M2 Delphi 1 2 3 4 5 6 7 With ADOQuery1 do begin  Close;   Parameters.ParamByName('Name').Value:=MyEdit1.Text;   Parameters.ParamByName('M1').Value:=StrToFloat(MyEdit2.Text);   Parameters.ParamByName('M2').Value:=StrToFloat(MyEdit3.Text);    Open; End;

Нужно не значениям базы присвоить значения edit, а edit присвоить значение параметра.
Типа
Вопрос состоит в том, как правильно составить SQL запрос в AdoQuery/

0

извините, но это бред!

Нужно не значениям базы присвоить значения edit, а edit присвоить значение параметра. Типа Delphi 1 2 3 4 5 6 7 With ADOQuery1 do begin  Close;   MyEdit1.Text:=Parameters.ParamByName('Name').Value;   MyEdit2.Text:=FloatToStr(Parameters.ParamByName('M1').Value);   MyEdit3.Text:=FloatToStr(Parameters.ParamByName('M2').Value);    Open; End;

наверное, вопрос в том: как показать ЗНАЧЕНИЯ полей в TEdit или DBEdit?

0

Сообщение от zremas извините, но это бред! наверное, вопрос в том: как показать ЗНАЧЕНИЯ полей в TEdit или DBEdit?

Гм... Почему бред то???
Нет, не в DBEdit...
В общем расскажу вкратце...
Есть форма с OPC клиентом. Соответственно он коннектится к OPC серверу, читает и пишет данные.
OPC сервер работает с ПЛК. В ПЛК хранится некий архив, на данный момент стоит задача синхронизация архива ПЛК и архива в MSSQL. Запись с контроллера в MSSQL я реализовал, а вот из MSSQL в ПЛК не выходит. Точнее выходит, но метод записи не устраивает (очень долго - 2c на запись) ибо необходимо передать 100 записей по одной....
На данный момент реализован следующий код записи из MSSQL в OPC сервер:
Где Form4 это форма OPC Клиента а Item это переменная программы в ПЛК. Плюс весь этот код крутится в теле таймера, но это совсем не важно.

Код SQL в ADOQUERY Такой:

Всё торможение происходит из-за постоянного открытия/закрытия AdoQuery.

Поэтому вижу только один выход из этой ситуации - это получение следующей записи из таблицы путём обновления запроса - "AdoQuery1.ExecSQL;".

В общем нужно присваивать так и только так:

Осталось просто составить правильный sql запрос.

0

весь концепт попахивает бредом.
--------------------------
Я правильно понял:
Получается, что некий цикл (a1:=a1+1 постоянно дергает sql запрос, каждый раз передавая новый ID.

0

Сообщение от zremas весь концепт попахивает бредом. -------------------------- Я правильно понял: Получается, что некий цикл (a1:=a1+1 постоянно дергает sql запрос, каждый раз передавая новый ID.

Почему бредом? Может у меня мозг уже отказывает.... Можете что то альтернативное предложить???
Да, вы правильно поняли....

0

решением может быть:
- вытащить на клиента ВЕСЬ датасет, созданный ОДИН раз на сервере для всех a1 от забора и до обеда
- на клиенте организовать цикл пробежки по принятому датасету и передаче данных в ПЛК

1

ExecSQL, батенька не поможет. Тем более, что метод этот применяется ТОЛЬКО для модифицирующих запросов.
В частности, для обновления данных (UPDATE).
Если постоянно менять параметр запроса для получения новых данных, то и хранимая процедура не поможет избежать упомянутых "тормозов".
А получение данных из таблиц базы возможен только с применением метода Open.
И не стоит здесь мудрить, потому как другого пути просто нет.
То что вы там пытаетесь показать, что "нужно присваивать так и только так:" относиться к выходным
параметрам хранимых процедур и, как выше сказано, ничем в увеличении скорости получения данных ХП не поможет.

Оптимизация скорости выполнения может быть только в одном - получить селективным запросом (SELECT) по возможности
как можно больше записей за один "Open" и с результатом запроса разбираться на клиенте (в программе).

1

Сообщение от zremas решением может быть: - вытащить на клиента ВЕСЬ датасет, созданный ОДИН раз на сервере для всех a1 от забора и до обеда - на клиенте организовать цикл пробежки по принятому датасету и передаче данных в ПЛК

То есть Вы предлагаете все записи таблицы БД запихнуть сразу допустим в DBGrid, а оттуда уже пробежкой в ПЛК гнать?
Можно... Я думал об этом... Но надеялся обойтись без DBGrid... К примеру хранимой процедурой... Ну да ладно... Так значит так... Завтра буду пихать всё в DBGrid.

Добавлено через 3 минуты

Сообщение от Скандербег ExecSQL, батенька не поможет. Тем более, что метод этот применяется ТОЛЬКО для модифицирующих запросов. В частности, для обновления данных (UPDATE). Если постоянно менять параметр запроса для получения новых данных, то и хранимая процедура не поможет избежать упомянутых "тормозов". А получение данных из таблиц базы возможен только с применением метода Open. И не стоит здесь мудрить, потому как другого пути просто нет. То что вы там пытаетесь показать, что "нужно присваивать так и только так:" относиться к выходным параметрам хранимых процедур и, как выше сказано, ничем в увеличении скорости получения данных ХП не поможет. Оптимизация скорости выполнения может быть только в одном - получить селективным запросом (SELECT) по возможности как можно больше записей за один "Open" и с результатом запроса разбираться на клиенте (в программе).

Опаньки! А вот про особенность ExecSQL подзабыл(((( Сори за поднятый кипиш....

Добавлено через 2 минуты
Всем спасибо за помощь! Дальше справлюсь)))

0

То есть Вы предлагаете все записи таблицы БД запихнуть сразу допустим в DBGrid, а оттуда уже пробежкой в ПЛК гнать?

Виноват, zremas, отвечу за вас (больше не буду).
Нет, нет и еще 100 раз "нет".
Когда компонент ADOQuery открывается и возвращает результат запроса - в нем как раз и сидят те данные, которые так нужны.
Грид используют только для отображения полученного результата.
Отсюда, как и сказано, надо будет пробежаться по ADOQuery (а не по DBGrid'у). Так что грид в этой ситуации не нужен.

0

Завтра буду пихать всё в DBGrid.

DBGrid тут непричем!
Достаточно ОДИН раз получить весь датасет для всего спектра a1, а потом организовать цикл по датасету ( а не по DBGrid)

0

Сообщение от Скандербег Виноват, zremas, отвечу за вас (больше не буду). Нет, нет и еще 100 раз "нет". Когда компонент ADOQuery открывается и возвращает результат запроса - в нем как раз и сидят те данные, которые так нужны. Грид используют только для отображения полученного результата. Отсюда, как и сказано, надо будет пробежаться по ADOQuery (а не по DBGrid'у). Так что грид в этой ситуации не нужен.

Не, енто само сабой... Грид нужен, для удобства сверки отправляемых и получаемых данных)))) Поэтому так))) Спасибо большое! Я дальше разберусь!)

Добавлено через 16 минут

Сообщение от zremas DBGrid тут непричем! Достаточно ОДИН раз получить весь датасет для всего спектра a1, а потом организовать цикл по датасету ( а не по DBGrid)

Как выше сказано DBGrid нужен только для удобства сверки.

0