- Что произойдет с аргументами этого канала если в какой-то момент времени, связь с сервером СУБД прервется, исчезнет таблица и проч.? - Произойдет ли подвисание МРВ, если указанный интервал пересчета канала окажется меньше чем физически может обработаться запрос? Или же просто произойдет сдвиг пересчета? - Как можно вытащить из таблицы СОСТОЯНИЕ_ПАРАМЕТРОВ (CODE_PARAM, STATE), включающая в себя 200 строк, 200 аргуметов одним запросом?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. При обрыве связи с БД значения аргументов канала SQL-запроса не изменятся.
2. SQL-запросы выделены в отдельный поток, поэтому любые задержки в исполнении этих запросов не вызовут подвисания МРВ. Цикл пересчета канала вообще не влияет на интенсивность запросов. Каждый запрос формируется, когда в этот канал записывается номер запроса из соответствующего шаблона. После исполнения запроса значение канала сбрасывается в 0. Если подавать значение нового запроса до сброса канала, то новый запрос не будет сформирован. Запросы, которые формируются разными каналами, устанавливаются в очередь, формируемую ODBC-драйвером БД. Строгой последовательности в этой очереди гарантировать нельзя.
3. Если ODBC-драйвер Вашей БД поддерживает в одном запросе нужное Вам число параметров, значит такой запрос можно создать и он будет реализовываться.
Posted by rorex_best (Участник № / Member № 1716) on :
... 3. Если ODBC-драйвер Вашей БД поддерживает в одном запросе нужное Вам число параметров, значит такой запрос можно создать и он будет реализовываться....
Я имею ввиду заполнение аргументов набором строк, а не одной единственной строки. Т.е. нужно из таблицы типа MyTBL (CodeParam, State) 0 100 1 50.5 2 17 ---- 49 16 Заполнить список аргументов запроса одним запросом ARG000 100 ARG001 50.5 ARG002 17 ---- ARG049 16
Как можно это реализовать? Для извлечения списка из 50 аргументов набором запрсов потребуется 50 обращений к БД на каждом цикле пересчета, что сильно тормозит процесс.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Сам стандарт SQL-интерфейса не позволяет сформировать запрос, который бы обновлял или вставлял больше одной строки. Вам придется "переориентировать" таблицу - аргументы запроса должны быть не строками, а полями (столбцами).
Posted by rorex_best (Участник № / Member № 1716) on :
Насчет [Сам стандарт SQL-интерфейса не позволяет сформировать запрос, который бы обновлял или вставлял больше одной строки...] можете попробовать 1. Оператор Insert для вставки более одной записи: insert into tblTest (CodeParam, StateParam) values (1, 50), (2, 30), (3, 45) ... (N, STATE_N); 2. Оператор Update для обновления более одной строки: update table tblTest set StateParam = StateParam & 31 where CodeParam between 15 and 25; Т.е. как видите интерфейс как раз таки и позволяет групповые вставки и групповые обновления. Он также позволяет делать выборку, включающую более одной записи: select * from tblTest; проблема в интерпритации данных на приемной стороне клиента. Т.е. я не могу в цикле от первой записи пока не конец заполнить таблицу аргументов. Ваш вариант действительно является выходом, но проблема в том, что при добавлении новых параметров, потребуется реструктуризация таблицы (т.е. добавление столбцов). В случае заполнения аргументов набором строк. При добавлении нового параметра в таблицу параметров, просто добавляется строка, что соответствует всем правилам 4 форме нормализации данных.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В TRACE MODE 6 нельзя считать одним запросом несколько строк из таблицы.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
А очень хочется! У меня была точно такая же задача. Суть её в хранении настроечных коэффициентов во внешнем хранилище. И естественно, хочется прочитать их все одним запросом! Т.е., допустим у меня таблица настроек регуляторов с полями: №рег., Кп, Ти, Тд и т.д. Как мне их все последовательно прочитать? - выполнить несколько запросов, изменяя "№рег.". Но это очень медленно. Я пытался ускорить этот процесс, используя несколько каналов CALL, вызывающих один шаблон запроса, но разные запросы - TM6.03 слетал 100%.
Хочу напомнить, что в ТМ5 была возможность обрабатывать многострочные запросы с помощью канала SQL_извлечь и выглядело это достаточно логично. Думаю, было бы правильным иметь некий атрибут в канале CALL, изменяя который можно было бы перебирать строки возвращенные в ответ на SELECT (например FPrnt - он вполне изменяется в реальном времени, но все равно надо перезапрашивать, вместо того, чтобы просто перебрать уже полученное - не выкидывайте данные до следующего запроса).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Использовали несколько каналов CALL и ТМ6 "слетал"? Не так давно пробовал подобным образом организовать 20 запросов (версия 6.04), сложностей не возникло. Обновляйтесь!
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
попробовал в 6.04 - вроде не слетает!
а в остальном согласны?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
