This is topic Работа с БД. in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Я не обращаю внимания, но при настройке подключения к БД Firebird 1.5.1.4481 через источник ODBC (Firebird_ODBC_1.2.0.70 драйвер) в списке выбора "DSN\Строка подключения" все доступные источники дублируются! Базовая версия ТМ 6.03.1, ОС MS Windows XP+Sp2. С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Внесено в базу.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые специалисты! Подскажите, пожалуйста, как оптимально организовать запись в базу данных (внешнюю по отношению к ТМ6) серию однотипных параметров многих единиц одинакового оборудования используя один шаблон связи с СУБД. Ведь если решать задачу «в лоб» то к каждой единице оборудования приходиться организовывать канал CALL для вызова шаблона связи с СУБД с конкретной привязкой параметров этой единицы оборудования. Может, есть возможность перепривязки аргументов шаблона с помощью атрибута ID канала CALL вызывающего шаблон связи с СУБД, тогда, как и какие параметры присваивать ID в режиме RUNTIME? Смотрел канал COLLECTION1, но это, по-моему, не то, что необходимо. Базовая версия ТМ 6.03.1. Заранее благодарю, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Надо использовать механизм перепривязки на уровне объектов. Такой пример описан в перепривязке экранов. Подобный механизм может быть использован для любых шаблонов.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые специалисты! К перепривязке на уровне объектов с целью использовать шаблон связи с внешней СУБД без множества каналов CALL я еще не дошел, но!! При решении проблемы «в лоб» (на один шаблон связи с внешней СУБД нацепил несколько каналов CALL) система начала работать нестабильно (зависает в профайлере). Однако подобная конструкция с шаблонами программ работает стабильно! БД Firebird 1.5.1.4481 через источник ODBC (Firebird_ODBC_1.2.0.70 драйвер) Базовая версия ТМ 6.04, ОС MS Windows XP+Sp2. С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пересчет программ - это наш внутренний поток с обозначенным приоритетом и четкой очередностью. Запросы к БД - это свой отдельный асинхронный поток, который обслуживается ODBC-драйвером БД. От его произовдительности и организации очередей зависит очень многое. Если его забить большим количеством транзакций, он может зависнуть.
Posted by M@V (Участник № / Member № 1800) on :
Добрый день. По поводу разных потоков я Вас понял, но я не произвожу большого потока транзакций - всего лишь два канала CALL запрашивающих транзакцию один раз в 5-ть циклов со смещением на цикл. Цикл монитора 0.25с. С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Итого 2 запроса за 1.25 сек. А если увеличить период запросов?
Posted by M@V (Участник № / Member № 1800) on :
Итак 2-е транзакции за 10-ть циклов со смещением на цикл. Цикл монитора 0.25с. Профайлер завис через 2 минуты, это лучше чем 20 секунд. Поэксперементирую еще и затем сообщу. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
Добрый день уважаемые! Сейчас у меня работают два канала CALL, запрашивающих транзакцию с БД(INSERT)один через 60 циклов другой через 80 циклов. Цикл=0.25с. Результат тот же - зависание через 1 - 2 минуты. Подскажите что делать далее. Базовая версия ТМ 6.04. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
В другом проекте я как-то не задумывался об отработках, потоках и подавал на вход канала CALL строб длительностью 5с. амплитудой равной номеру запроса и при цикле монитора 0.1с у меня происходило 3-и транзакции, без каких либо проблем и зависаний правда канал работал один, конечно часть запросов скорее всего игнорировалась. С SIAD получить какую либо выборку это целые проблемы, не говоря уже об экспорте в текстовый файл с последующей закачкой в нормальную базу, которая отвечает на SQL! Подскажите, что делать. А в это время я попробую повозиться с перепривязкой канала. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
Привожу выдержку из топика Архивирование в Access : «Обращение к СУБД через ODBC - процесс однопоточный, пока не завершился текущий запрос, новый запрос этим же каналом инициировать нельзя. Завершение запроса - это сброс значения канала вызова SQL-запроса в ноль. Пока он не сбросит свое значение - новый запрос будет просто игнорироваться.» Я так понимаю, что каналы класса CALL (с периодом пересчета не IDLE) выполняются в основном потоке монитора, а шаблоны связи с БД (SQL запросы) в асинхронном потоке, а посему вопрос: система должна игнорировать обращение к CALL в основном потоке до завершения запроса (сброс значения в ноль), что недолжно приводить к ее зависанию??? С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Не все каналы класса CALL обрабатываются в основном потоке, даже если они не имеют период пересчета IDLE. Только вызовы программ. Остальные реализуются в асинхронных потоках, имеющих разные приоритеты. Зависания МРВ при обращении к БД не должно быть, если драйвер ОДВС корректно завершает переданный ему запрос. Не можете ли Вы в экспериментальном варианте вместо БД Firebird использовать общедоступную MS Access? И включить трассировку ODBC-обмена, чтобы можно было увидеть, что происходит, если ситуация воспроизведется. А там и мы на этой БД сможем воспроизвести и проанализировать ситуацию на Вашем проекте и Вашей БД.
Posted by M@V (Участник № / Member № 1800) on :
Добрый день, уважаемые! Итак, MS Access работает по полной программе (2-4 транзакции в секунду) и никаких сбоев не дает. Правильно ли я делаю выводы, что проблемы либо в Firebird_ODBC_1.2.0.70 драйвере, либо в самой БД Firebird 1.5.1.4481? И еще, если у Вас есть время и желание, то могу выслать протокол трассировки по Firebird_ODBC. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
Добрый вечер, уважаемые! Действительно, Вы оказались правы, все дело в том, как отрабатывает драйвер ODBC. И, к сожалению Firebird_ODBC_1.2.0.70 ведет себя плохо! Подыскал другой драйвер ODBC для БД Firebird, и все нормально заработало!!! Правда не знаю на долго ли? С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
С понедельником Вас, уважаемый МОДЕРАТОР! Ну, как в воду глядел, мое удовольствие быстро закончилось. Зависания профайлера продолжаются, только значительно реже. Все равно мне не совсем понятно это поведение профайлера ну завис асинхронный поток да и черт с ним ведь когда гашу ядро FIREBIRD все работает отменно. Тем более, наблюдая за ресурсамн с помощью менеджера задач, я не вижу чтобы ктото их кушал немеренно, всего максимум импульсы по 40%. Теперь о наболевшем: 1. ВАШ форум по SIAD ВЫ аккуратно захлопнули, мотивируя, что в эту БД очень быстро пишется, ну ВЫ как журналисты со своей стенографией, быстро пишут, только, кто в этом разберется. И действительно, не понятно ли ВАМ, что реализация немногих выборок из SIAD все равно не удовлетворит большое множество реляционных запросов пользователей. 2. Отдать стандартный SQL пользователям, это святая святых, только предупредите их, что это на ваш стах и риск, или ВАША супер база слабо? Где-то на форуме читал, что человек был в шоке 4-дня от ответа, что драйвера ODBC к SIAD и не планируется, хотя ранее обещали, что он в разработке, неужели это ВАМ приятно? 4. Может, я ошибаюсь, и платная версия работает отменно, тогда, как же плохо ВЫ завоевываете потенциальных клиентов. 5. И, в конце концов, решите ли ВЫ исправлять свои огрехи заплатами или SP, как это делает наш конкурент MICROSOFT или качать по 120МБ и ждать нового релиза, ведь это операционная система реального времени? 6. Я стою перед дилеммой покупки лицензионного продукта, за который разработчик должен в некоторой мере нести ответственность, и что я должен приобрести, кота в мешке или то, что описано в документации? В случае невыполнения документированных обязательств, кто мне вернет затраты? Или Вы ответите, что продукт я покупаю, так как есть!? Прошло довольно много релизов, много клиентов слетело с форума, отдав предпочтение другим продуктам, кстати, Вы ведете такой анализ? За брата обидно, РОССИЮ, ведь я знаю, какой продукт ОНА может сделать, и даже сладиться с драйверами ODBC к FIREBIRD, ведь это наш продукт и бесплатен, а ВЫ говорите ACEES! 7. Наконец, я перед руководителями не смогу оправдать свой выбор, обещая им, что все будет лучше с течением времени. Прошу Вас МОДЕРАТОР ответить на вопросы, как полагается организации с быстрым временем реагирования, или такой сервайс только для приобревших проблему! Извините, наболело, с уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Разработка программного продукта осуществляетсяв соответствии с техническим заданием, сформированным с учетом опыта эксплуатации предыдущих версий, функциональных возможностей современных аналогичных систем других разработчиков и актуальных потребностей пользователей. В любом случае разработчик оставляет за собой право решать вопросы функциональной насыщенности продукта и очередности решений по его модернизации. Покупатель вправе решать, подходит ли ему этот продукт по совокупности всех функциональных, технических и экономических параметров и предлагаемого сервиса. 2. Характеристики базовой и профессиональной версий TRACE MODE 6 одинаковы. Они отличаются только некоторыми функциональными возможностями, что оговорено в справочной системе. 3. Выпуск очередного релиза, а это происходит 3-4 раза в год, связан не столько с исправлением обнаруженных ошибок, сколько с существенной функциональной модернизацией, развитием системы. Работа над кодом идет практически непрерывно. Каждый релиз проходит весь производственный цикл, включая полноценное тестирование. В этих условиях выпуск патчей с целью исправления отдельных ошибок осуществляется только в исключительных случаях на условиях особых договоренностей. Так будет, видимо, и впредь. 3. Что означает "наш продукт" по отношению к FIREBIRD, мне непонятно. Однако Вы сами пишете, что его ODBC-драйвер обладает некоторыми особенностями, которые меняются от версии к версии. Отслеживать индивидуальные особенности драйверов ODBC, которые каким-то образом влияют на отработку стандартных SQL-транзакций, крайне затруднительно. Сейчас мы, например, вынуждены вплотную заняться проблемой интерфейса с MS SQL-2005, поскольку в отличие от своего предшественника MS SQL-2000 он создает определенные проблемы при попытках запросов схем его БД. Отработать механизмы всех обмена на всех вариантах поставляемых ODBC-драйверах не представляется возможным.
Posted by M@V (Участник № / Member № 1800) on :
Очень благодарен за Ваши разъяснения! А особенно за заметку по MS SQL-2005, ведь хотел повозиться с ним, теперь понимаю, что необходимо работать с MS SQL-2000. И еще, не подскажите ли как себя ведет MS SQL7? С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Тестирование работы ТМ6 с MS SQL7 не проводилось.
Posted by ВалерийЛ (Участник № / Member № 1664) on :
Позволю себе поделиться своим опытом, может кому-то поможет. Правда у меня была задача извлекать данные из базы, думаю это не принципиально. У меня сразу сложилось впечатление, что проще структуру базы подстроить под ТМ, фактически сформировать новые таблицы в одну строку, но конечно же это реально только для учебных целей. Тогда запросы отрабатывались бы идеально, но перейдем к реалиям. По-моему никакая перепривязка и использование COLLECTION не поможет, тем более все-равно с точки зрения запросов нелогичность остается, т.е. дробление запроса до одного параметра, во всяком случае мне не удалось решить проблему. Теперь к решению в лоб. Как только создается несколько каналов CALL по одному шаблону, профайлер уходит в "астрал" через 1-5 минут уже не чень- то зависимо от их количества (CALL). Вывод-количество шаблонов даже однотипных (что опять не логично) необходимо создавать по количеству параметров, и каналов CALL ( у меня их было 75). Честно говоря результат работы такого варианта я уже не помню, т.к. давно это было. А вот последний вариант работает без зависаний, по крайней мере до ограничения времени работы профайлера базовой версии ТМ: я оставил все-таки 75 шаблонов ,но с 1 каналом CALL и одной программой с гарантированной последовательной отработкой запросов по-одному в реальном времени.
Posted by M@V (Участник № / Member № 1800) on :
Добрый день, Валерий! Уточните, пожалуйста, У Вас использовался один шаблон связи с СУБД в котором было 75 запросов и Вы работали с ним с помощью одного канала CALL меняя номер запроса, или как то по другому? Если можно и не затруднит, то вышлите пример на мыло Заранее благодарен, Александр.
Posted by M@V (Участник № / Member № 1800) on :
Извините, в дополнение к предыдущему посту. Или у Вас было 75 шаблонов связи с СУБД и 75 каналов CALL (по одному на каждый шаблон связи с СУБД) и всего одна управляющая программа, вызывающая по очереди каждый канал CALL? Уточните пожалуйста. С уважением, Александр.
Posted by ВалерийЛ (Участник № / Member № 1664) on :
Да, использовался один шаблон связи с СУБД с 1 каналом CALL , в котором было 75 запросов с 75 аргументами и сменой параметра запроса с помощью программы.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые господа, поэксперементировал с разными базами: Firebird 1.5.1.4481 и DB2 v9.1.200.166 через источник ОДБС и вот что получил при замере быстродействия с помощью DELPHI6.0: Firebird 1.5.1.4481 - 1 полная транзакция за 3.2мс DB2 v9.1.200.166 - 1 полная транзакция за 0.55мс Выполнял запрос INSERT аналогичный ТМ6.05.1. При работе с этими базами и ТМ6.05.1 через ОДБС получаю противоположные результаты: Firebird 1.5.1.4481 - 1 полная транзакция за 250мс DB2 v9.1.200.166 - 1 полная транзакция за 2000мс Конечно напршиваются вопросы: 1. Почему просходит такое резкое падение производительности? 2. Почему Firebird 1.5.1.4481 покосил DB2 v9.1.200.166? Правда серверы у меня работали на той же машине что и базы данных. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
Прошу прощения, базы данных работали на той же машине что и ТМ6.05.1. С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы не считаем SQL-интерфейс основным интерфейсом в работе с реальными технологическими процессами. Поток SQL-запросов в Trace Mode отнесен к самым низко-приоритетным, чтобы он не препятствовал мониторингу, диагностике и управлению в реальном процессе. Возможно, что на специально выделенном МРВ можно сократить период обработки каналов и повысить приоритет этого потока с тем, чтобы повысить его производительность. Что касается разницы между Firebird и DB2, то МРВ совершенно инвариантен к типу БД. Он работает через соответствующий ODBC-драйвер БД. Все различия здесь могут быть только в реальном интерфейсе этого драйвера с БД и реальной загрузке ПК, использующего эту БД.
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
отважусь вставить свои 5 копеек про базы данных. замечательная внутренняя база TM настолько неудобна что в проекте который выполнила наша фирма мы использовали для архивирования просто запись срезов по всем данным в csv-файл при помощи своей DLL. так же рассматривалась возможность дописания приложений для работы с этим csv-файлами что бы их можно было просматривать в графическом и табличном виде, а так же делать выборки и экспорт поскольку средства TM для этой цели малопригодны... впрочем - это болезнь всех SCADA которые я когда-либо видел Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Тот факт, что Вы испытываете неудобства в конкретном проекте в решении конкретно Вами поставленной задачи, еще не говорит о том, что "внутренняя база TM настолько неудобна". Нельзя абсолютизировать как постановку задачи, так и методы и средства ее решения. Всегда существуют варианты. Но в конечном счете успех решает дело. Вы нашли решение, и это хорошо.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемый модератор, подскажите алгоритм выполнения каждого запроса в ТМ6.05.1 через драйвер ОДБС, я понимаю так: 1. ТМ6.05.1 запрашивает установку коннекта через ОДБС с SQL базой. 2. ТМ6.05.1 запрашивает старт транзакции. 3. ТМ6.05.1 запрашивает выполнение запроса. 4. ТМ6.05.1 запрашивает завершение транзакции. 5. ТМ6.05.1 запрашивает отключение коннекта с SQL базой. И так по каждой инициализации канала CALL запроса к БД. Меня именно интересует момент установки коннекта, происходит ли он каждый раз при выполнении запроса или единыжды при старте монитора? Если каждый раз то мне тогда понятны временные задержки. Заранее благодарен за внимание, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Каждый успешный запрос завершается дисконнектом. Новый запрос начинается с коннекта.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые господа, я так понимаю, что связь с SQL базой осуществляется либо по DSN прописанному в Администраторе источников данных ОДБС, либо по строке подключения, содержащей ключевое слово DRIVER= с указанием имени драйвера обязательно зарегистрированого в Администраторе источников данных ОДБС. Потому что любые попытки установить коннект с помощью других провайдеров приводят к жалобе ТМ6.05.1: "Подключение... [Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию QODBC3: Unable to connect". С увжением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Именно так.
Posted by M@V (Участник № / Member № 1800) on :
Не будет ли любезна уважаемая «АДАСТРА» в следующих релизах предоставить возможность управления алгоритмом связи с внешними базами данных в среде IDE(коннект при каждом зпросе, либо в начале сессии с периодической проверкой через NN-секунд и т.д.) либо програмно по аттрибутам канала CALL. Или этот момент аргументировано исключается? Ведь согласитесь, абсолютно надежных каналов не существует, и каждый требует своей тонкой настройки. С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В ближайшем релизе таких возможностей не будет. В целом алгоритм взаимодействия с БД в перспективе будет пересматриваться.
Posted by M@V (Участник № / Member № 1800) on :
Доброго времени. Нормальное решение принял InSAT: работа с SQL базами на уровне внутренних процедур SQL ядра. Довольно быстрая связка, при использовании провайдеров. Правда модули связи платные. С уважением, M@V.
![[Неодобрение / Frown]](frown.gif)