|
Сообщение создано: 09. 10. 2011 [08:53]
|
|
NestorIT
Евгений Канашев
Создатель темы
Зарегистрирован(а) с: 29.09.2011
Сообщения: 3
|
Решили попробовать OpenSCADA в связке с PostgreSQL. Все было прекрасно до момента попытки архивирования параметра при помощи "Архив на БД" - при добавлении параметра получаем сообщения об ошибке в логе OpenSCADA. Ругается на ALTER TABLE. Лог БД оказался более информативным, в нем удалось увидеть что именно не так. Вот запрос из лога PostgreSQL (с точностью до наименования параметра, разумеется, и записанное чуть более наглядно):
ALTER TABLE "DBAVl_ARH2_P1_MyData"
DROP CONSTRAINT "DBAVl_ARH2_P1_MyData_pkey",
ADD "TM"
ALTER TABLE "DBAVl_ARH2_P1_MyData"
DROP CONSTRAINT "DBAVl_ARH2_P1_MyData_pkey",
TIMESTAMP WITH TIME ZONE DEFAULT '1970-01-01 05:00:00' ,
ADD "TMU" INTEGER DEFAULT '0' ,
ADD "VAL" INTEGER DEFAULT '0' ,
ADD PRIMARY KEY ("TM","TMU")
Очень интересным оказалось вхождение ALTER TABLE дважды, причем второй раз явно не к месту появляется начало того же запроса.
Здравый смысл подсказывал, что надо искать проблему в модуле, отвечающем за PostgreSQL, ибо с другими БД таких проблем не возникало. В файле src\moduls\bd\PostgreSQL\postgre.cpp нашлась прелюбопытная запись в методе void MTable::fieldFix( TConfig &cfg ), а именно в 803 строке:
f_tp = req+"TIMESTAMP WITH TIME ZONE DEFAULT '"+UTCtoSQL(atoi(u_cfg.fld().def().c_str()))+"' ";
притом, что для любых других типов данных при формировании строки f_tp величина req (как раз и содержащая ALTER TABLE ... DROP CONSTRAINT ...) не используется.
У себя то мы пофиксили - теперь работает, может кому еще информация пригодится.
|
|
Сообщение создано: 09. 10. 2011 [11:01]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Исправлено.
Learn, learn and learn better than work, work and work.
|
