Gin
Junior Member / Новичок
Участник № / Member № 1316
отправлено / posted
Существует ли способ получить архивные значения каналов из СПАД во внешнюю БД, например Access? Как доставать текущие значения по ODBC через SQL-запросы я разобрался. Но меня интересуют именно архивные. Подскажите пожалуйста, как это можно сделать!
Сообщения / Posts 1 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Драйвер ODBC к СПАДу 6-й версии не готов. Как вариант - делать выборку из СПАД каналами ТМ6 и передавать значения SQL-запросами.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
ODBC-Драйвер для 6-й версии не планируется. Мы считаем, что в целях безопасности работы системы МРВ в реальном времени, недопустимо предоставлять интерфейс, по которому можно передавать неограниченные объемы данных, влияя тем самым на устойчивость системы. Таким образом - лучшим решением задачи будет копирование архивной информации для внешних СУБД в виде структурированных текстовых файлов - а это штатная функция системы ТМ.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
Я четыре дня находился в шоке от вашего заявления и намеревался написать развернутый ответ со злобной критикой, но вместо этого предложу рассмотреть задачу:
Работает проект на несколько тысяч каналов без всяких связей с внешними базами данных, либо со сбросом туда неких итоговых результатов, как это обычно делается. Происходит нештатная ситуация или проводятся кратковременные или даже длительные испытания. Подходят ко мне разные люди, которым нужна информация по десяткам или сотням каналов в цифровом виде за разные периоды времени в разном сочетании с разным шагом. Как мне с удаленного компьютера (например, Глобальный регистратор) не останавливая проект взять эту информацию? Или напечатать графики по нескольким параметрам? С помощью SIAD_Util.exe, предварительно экспортировав ВСЕ каналы в текст, а потом разгребая все это?
Нет, не сдержусь... А чем вообще будет тогда заниматься Глобальный регистратор, кроме сбора данных, если взять их оттуда нельзя? Нонсенс - сервер базы данных, у которого данных не выпросишь! Помнится, то же было говорено и про пятую версию, но там хоть дела наладились и худо-бедно ODBC работает.
А если я вообще не хочу использовать ваш генератор отчетов или мне в отчёте статистические рассчеты придется делать, а я ещё не знаю какие и лезть потом в работающую систему реального времени, чтобы добавить и подгрузить отчет, нет никакого желания? Да и тренд мне ваш пока не нравятся, я намеревался сделать свой, работающий через ODBC как внешнее приложение (с печатью, с сохраняемыми наборами).
Вместо того, чтобы отладить SQL и сказать: "Вот вам данные в красивом виде - делайте что хотите", вы взваливаете на себя еще и их обработку.
Мне видятся новые проекты на ТМ6 как МРВ без архивов + OPC-сервер + Внешняя система регистрации с нормальным SQL. Собственно мы и сейчас уже вынуждены так делать на ТМ5, т.к. с большими SIAD работать не удобно, а в маленькие много не входит и ODBC работает медленно.
ТАК НАДО ЧТОБЫ РАБОТАЛО и БЫСТРО, и чтоб не только самые примитивные запросы выполняло, а ещё и с заданным шагом и с заданным количеством точек на диапазоне выборку делало!!!
А за безопасность вы не беспокойтесь, если математика у вас будет отлажена, то об остальном мы позаботимся. ТМ5, кстати, отдает мне данные по несколько раз в сутки и не кашляет.
Удачи вам и большого везения на рынке!
Прошу высказываться участников форума, объясните мне в чем я не прав, я буду рад, если вы меня переубедите!
Сообщения / Posts 338 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Если сделать так, как предлагаете Вы, то SQL-запросы к базе данных не будут контролироваться системой реального времени TRACE MODE. Поэтому пользователь будет иметь возможность написать такой SQL-запрос, который потребит значительную часть вычислительных ресурсов системы, что может привести к нарушению ее работы, или даже к остановке. Поэтому в ТМ6 мы расширили функции математической обработки архивных данных в реальном времени. Мы считаем этот путь правильным, обеспечивающим надежность и предсказуемость работы системы реального времени, на долгие годы ее эксплуатации.
Для работы с историческими данными предусмотрены следующие механизмы:
- исполнение SQL-запросов к внешним СУБД. Это позволяет, например, вести всю историю процесса в реляционной базе (базах) через ODBC (поэтому конструкция МРВ+OPC+СУБД не требуется. Однако, следует предупредить - реляционные СУБД в сотни раз медленнее чем SIAD.
Также средствами TRACE MODE 6 можно:
- сделать выборку из SIAD; - провести ее матобработку; - вывести ее в виде тренда или таблицы; параметры выборки (от, до, шаг, выбираемые каналы ...) можно менять в реальном времени.
- расширены возможности статистической обработки данных в реальном времени - например, подсчет сумм с нарастающим итогом, усредненных значений и т.д.
- любая выборка из SIAD может быть экспортирована в текстовый файл по команде в реальном времени. Также может быть экспортирован архив за произвольный интервал времени.
- копирование архива в реальном времени по команде и экспорт в txt-файл, с последующим доступом по ODBC.
Кроме того, в TRACE MODE 6 есть такая новая возможность как горячая замена любого компонента проекта. Она позволяет вносить в работающий проект изменения без остановки или перезагрузки. Это позволит добавить в проект те функции (каналы, SQL-запросы и т.д.), которые были "забыты" на этапе проектирования.
Есть еще и другие возможности работы с архивом TRACE MODE, не влияющие на МРВ, но, как нам кажется, и вышеописанные функции уже решают поставленную Вами задачу.
AlexeyUkaTM6
Junior Member / Новичок
Участник № / Member № 2002
отправлено / posted
Возвращаясь к напечатанному!
С покупкой 6 версии мы думали, что проблема архивирования значений во внешнии базы данных будет решена. Однако, это к великому разочарованию, оказалось не так. SQL запросы оказались однопоточными хотя нигде в хелпах об этом не написанно. При достаточно большом потоке данных(через OPC данные тянуться примерно по 1000 каналам) записываются в базу данные только первого запроса, остальные просто теряются. Сам ТМ6 как SCADA-система работает нормально, но как мне отдать данные которые я получаю с объектов дальше, например, в бухгалтерию или в ГИС-систему в реальном времени по изменению состояния канала или по изменению потребления по какой-либо линии. Может Вы предложите какое-то решение данной проблемы? И я полностью согласен с господином Kramarenko Stanislav цитирую: "Нонсенс - сервер базы данных, у которого данных не выпросишь!" Ковыряться в текстовых файлах которые получаются при эксорте из СПАД-архива не устраивает: во-первых, это уже архивные данные, а не данные реального времени, а во-вторых действительно довольно трудоёмко с ними работать. Может стоит сделать возможность обработки SQL-запросов в несколько потоков, но ограничить возможность написания больших запросов? Ведь много та не требуется, достаточно передовать только реальные значения каналов по их изменениям. А передовать значения в другие приложения я думаю всё равно прийдётся, либо средствами Трейс Моуда, либо искать какие-то другие способы.
Константин Арапов
Forum Member / Участник форума
Участник № / Member № 1998
отправлено / posted
Присоединяюсь к Kramarenko Stanislav и AlexeyUkaTM6. База данных подразумевает не только запись в нее, но и выборку. И как не крути, ничего лучшего для выборки чем SQL еще не придумали. SQL не поддерживается, а выборка средствами TM6 не всегда есть то что нужно. Так что мне кажется разработчикам нужно либо реализовать первое, либо довести до ума второе.
Сообщения / Posts 32 | Из / From: Россия
| IP / IP: IP адрес / IP address |
rorex_best
Forum Member / Участник форума
Участник № / Member № 1716
отправлено / posted
Присоединяюсь к Kramarenko Stanislav и AlexeyUkaTM6, Константину Арапову.
Лучше реляционных хранилищ данных еще ничего не придумали: - прозрачность их использования (возможность работать через ODBC), - обеспечение безопасности доступа (благодаря выдаче привилегий), - многопользовательская система, - средство разработанное всем человечеством, над которым трудились математики, программисты, полученное потом миллионов, легко адаптируется под любые задачи, являясь самым универсальным способом хранить и обрабатывать данные.
Чтобы создать что-нибудь схожее по возможностям придется потратить на разработку не одно 10-летие, в противном случае будет очень урезанное средство с очень ограниченными возможностями.
Думаю, что демократичный вариант при котором будет выполняться полная поддержка SQL/ODBC и продвигаться SIAD будет самым правильным решением.
Думаю каждый разработчик имеет право на выбор хранилища данных! Пусть все решит его величество СПРОС.
Сообщения / Posts 31 | Из / From: Россия
| IP / IP: IP адрес / IP address |
sergey UralSteel
Forum Haunter / Завсегдатай форума
Участник № / Member № 1914
отправлено / posted
AdAstra Technical Support Moderator Участник № / Member № 4
отправлено / posted 04-03-2005 13:23 -------------------------------------------------------------------------------- Драйвер ODBC к СПАДу 6-й версии пока еще не готов. Как вариант - делать выборку из СПАД каналами ТМ6 и передавать значения SQL-запросами.
отправлено / posted
Не понятно, что Вы имеете ввиду под драйвером. В релизе 6.07 будет реализована возможность групповых записей из БД в архив SIAD. Из SIAD в БД можно писать групповым образом уже в релизе 6.06.2
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[Недоумение / Confused]](confused.gif)
и намеревался написать развернутый ответ со злобной критикой, но вместо этого предложу рассмотреть задачу:
