This is topic Запись в БД in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/31/t/001129.html

Posted by SergeyZ86 (Участник № / Member № 5575) on :
 
Вопрос по видео уроку "Обмен данными между SCADA TRACE MODE и СУБД по ODBC". Для чтения значений из БД в канал CALL.SQLQuery.In необходимо записать 0xFFFF. Этот процесс описан в разделе "выполнение SQL-запросов в реальном времени" и здесь вопросов не возникает. Что касается записи в БД, на видео уроке по нажатию кнопки "Выполнить вставку строк" производится запись 2 в какой-то атрибут канала CALL.SQLQuery. Хотелось бы знать в какой, и почему записывается именно 2. Можно ли скачать данный демонстрационный проект? И еще, обязательно ли при записи в БД включать в запрос Insert поле RegionID ведь поля PrimaryKey в БД(по крайней мере в Access2007) заполняются автоматически?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. "Хотелось бы знать в какой, и почему записывается именно 2."

Значение передается в атрибут "Входное значение" канала "База_данных#2:2". Передается двойка, чтобы записать в базу данных две строки (описание двух регионов по видеоролику).
Мы можем выслать пример Вам на почту. Укажите адрес.

2. "И еще, обязательно ли при записи в БД включать в запрос Insert поле RegionID ведь поля PrimaryKey в БД(по крайней мере в Access2007) заполняются автоматически?"

Для Trace Mode это не имеет значения. Наша SCADA отправит в драйвер ODBC тот запрос, который забит в редакторе. А вот для базы данных это существенно. Если, например, столбец является обязательным для заполнения, и он не заполняется автоматически, то для успешного выполнения SQL-запроса запись столбца необходима.
 
Posted by SergeyZ86 (Участник № / Member № 5575) on :
 
Спасибо за ответ! Моя почта: xxx@yyy.ru Еще один вопрос. Почему-то не работает запрос на групповую выборку, написанный через мастер запросов. Пишу тот же запрос вручную - все работает. С чем это может быть связано? Заранее благодарю.

[ 28.11.2012, 09:50: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Проект отправили.

2. Вероятней всего, есть какое-то различие в запросах.

В тех случаях, когда SQL-запрос не выполняется нужно включать трассировку ODBC и по файлу лога смотреть, что происходит.
 
Posted by Gvenihvivar (Участник № / Member № 5513) on :
 
Вышлите, пожалуйста, и мне пример проекта к этому видео на почту: xxxxxx@yyyyyyy
Видео сегодня не доступно, его совсем убрали или вернут?

[ 20.06.2013, 14:41: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Отправлен проект.
Ссылка временно не работает.
Приносим свои извинения.
 
Posted by Gvenihvivar (Участник № / Member № 5513) on :
 
Был разработан проект на основе примера. Когда запись велась в базу данных по нажатию кнопки, записывались все аргументы значащиеся в канале Call. Как только запись в БД автоматизровали с помощью программы, записываться стал только значение первого аргумента со всех каналов Call.
Как с этим бороться?
И еще: было настроено запись миллисекунд из атрибута 88 канала Time. Сам атрибут пишется, но при 4 записях за секунду значения всех миллисекунд одинаков. Такое впечатление, что ТМ просто тиражирует запись в зависимость от длины цикла пересчета.
Можно определить заранее сколько времени нужно системе на выполнения записи?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Кнопка с экрана передает в CALL.SQL только заданное значение.
Программа всегда передает в свой аргумент какое-то значение. В программе необходимо обеспечить отсутствие сброса на входе CALL.SQL до тех пор, пока запрос не будет исполнен.

2. Значение мс в атрибуте 88 изменяется с циклом пересчета канала. 4 записи в секунду может оказаться слишком частым и для цикла пересчета и для ODBC-драйвера.
 
Posted by SergeyZ86 (Участник № / Member № 5575) on :
 
Здравствуйте. В моем проекте программно осуществляется запись определенного параметра с меткой времени в БД Access. Запись собственно начинается по нажатию кнопки, при этом в аргумент Arg000 канала Call.TVC через канал Time передается метка времени начала записи, и заканчивается по нажатию др. кнопки, соответственно метка времени посылается в аргумент Arg001. Частота записи значений в БД так же задается программно. После записи мне необходимо вывести значения параметра на архивный тренд во временном диапазоне, заданным аргументами Arg000, Arg001 канала Call.TVC. Но в атрибут 142 канала Call.TVC значения не пишутся. Если отвязать каналы Time от Arg000, Arg001 то в канал Call.TVC записываются все данные из БД. Проверял через окно Просмотр Компонентов, метки времени, записываемые в Arg000, Arg001 строго соответствуют первой и последней метке времени, записываемой в БД. Подскажите пожалуйста, в чем может быть причина отсутствия значений в канале Call.TVC...
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Речь, видимо, идет о формировании в канале TVC кривых, считанных из БД.
Временной диапазон выборки для SQL-запроса не должен задаваться аргументами канала TVC, в который записываются результаты выборки.
Arg000 и Arg001 канала TVC должны индицировать временной диапазон, не задаваемый для выборки, а получаемый в процессе считывания из БД.
Собственно временной диапазон выборки должен задаваться в запрос SQL.SELECT от каналов TIME_beg и TIME_end, или непосредственно от соответствующих аргументов запроса SQL.SELECT, в которых фиксируются соответствующие временные метки.
 
Posted by SergeyZ86 (Участник № / Member № 5575) on :
 
Большое спасибо!
 
Posted by SergeyZ86 (Участник № / Member № 5575) on :
 
А у вас есть примеры построения подобных SQL-запросов с конвертированием меток времени из строкового формата Trace Mode 6 в формат Access 2007???
И еще, скажите пожалуйста, где можно прочитать, как пользоваться трассировщиком ODBC. В справочной системе к сожалению нет никакой информации...
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Формат времени, передаваемого из Trace Mode 6, соответствует региональным настройкам ОС. БД также должна соответствовать этим настройкам.

2. Трассировщик должен быть представлен в описании используемого драйвера ODBC.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
quote:
Отправитель / Originally posted by AdAstra Technical Support:
1. Формат времени, передаваемого из Trace Mode 6, соответствует региональным настройкам ОС. БД также должна соответствовать этим настройкам.

Неа. Не так. БД допустим MS SQL, переведет в свой формат времени любое время. Т.е Можно писать нашь русский формат времени(день/месяц/год/час/минута/секунда), в БД MS SQL он все равно будет (год/месяц/день/час/минута/секунда) американским.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Не все БД обладают такими хорошими свойствами.
 
Posted by 19216803 (Участник № / Member № 6114) on :
 
Отправьте и мне пример пожалуста
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
О каком примере идет речь?
 
Posted by dus_112 (Участник № / Member № 9122) on :
 
"Отправлен проект.
Ссылка временно не работает.
Приносим свои извинения."

Вот об этом.
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
Ответ дан почтой.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2