Corba_Exception due to polling of attribute

Hello Manu/Andy

Please find the attached result of the command 'DbGetDataForServerCache'. One is before defining polling and archive periodic event and the other file is after defining polling and archive periodic event.

Thanks and Regards
tgmrt
Regards,
TCS_GMRT
Hello,

For which of the two cases, your DS start with error? I guess it is the second case but this is not coherent with the reply of the
select I ask you to do in one of my previous post. In this select result, there was 6 (and only 6) polled attributes which were
- alarmid
- alarmlevel
- alarmmsg
- responsefield
- alarmtoollevel
- alarmtoolmsg
and this is what I see in the result of the DbGetDataForServerCache command in case 1
In case 2, the number of polled attribute is 53 (the same first 6 plus many other).

What could help us is the output of your device server when it fails to start (with -v5 on command line) and the result
of the DbGetDataForServerCache executed just after.

Regards

Emmanuel
Hello,

After our phone call, I did the following with one of my test device server: For a device with 2 dynamic attributes, I
have in Jive selected the Polling page, then all the device attributes and start polling for all of them (using right click menu).
Then stopped and started the DS -> everything OK.
Then for the same device (therefore with all its attributes polled), I have selected in Jive its Event/Archive event page and once again selected all device attributes to set the polling period to 1000mS (using right click menu)
Then stopped and started the DS -> everything OK.

I agree I am using Tango 9 and Jive 6.9 but I don't think it is relevant here.
Therefore, our advice is to fix your database and try again once it is done

Regards

Emmanuel
Hi TCS-GMRT team,
I also did a test with PyTango9 (branch on github) subscribing to events using the FQN and it works. I have not tested it on PyTango8 to see if the same code is broken.

I took a closer look at the problem you have with the corrupted database due to extra columns you added to the device_attribute_property table. I must admit I do not understand why changing the period of the archive or periodic event causes you to loose values. The database server is doing DELETE and INSERT actions on the tables using the column names. The code in question is in the method
DataBase::db_put_device_attribute_property2
Why this messes up with the extra columns is a riddle to me. But as Manu said - first try to reproduce the problem without the extra columns.

Cheers
Andy
Edited 8 years ago
 
Register or login to create to post a reply.