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 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 |