Still having problems archiving alarms.

[AndrewWilliams]

Hello,
I posted a message a short-while ago regarding a problem I have with archiving alarms/events in Labview DSC 7.1. Since I am still having the problem, I am posting some more details.

When my application executes, the Tag Engine logs traces and alarms/events to a database called Data (configured in the .scf). I wish to archive this database to a separate directory, that can then be copied and pasted elsewhere. To allow the copying/pasting I first create/reattach the archive database (called LocalArchive), execute the Archive Traces.vi to archive the trace data, execute the Archive Alarms & Events.vi to archive alarms/events, then detach LocalArchive. However the detach phase always fails with the error message "HIST_Detach
Database.vi, Citadel: (Hex 0x8ABC102B) Failed to detach associated relational database."

I have made the following observations:

i) after waiting about 1 minute then retrying Detach Database.vi, it works. When executing the archiving VIs, I ensure that the archive status bar is visible; the Archive Alarms & Events status bar fills VERY quickly. Could this status bar be 'lying' to me, i.e. it takes about a minute longer, hence detaching works fine if I leave it about a minute.

ii) if I don't archive the alarms/events then detaching works fine (i.e. when archiving trace data only). The status bar for trace archiving fills at a rate I would expect.

iii) trying to detach the database in Historic Data Viewer also fails (unless I wait about 1 minute after archiving).

iv) if instead of detaching the database, I choose to delete it, then there are no problems (using either Delete Database.vi of Historic Data Viewer).

If anyone could offer any advice it would be much apprecia
ted. In particular, has anyone else seen this problem, or does anyone else suspect that the alarm archive status bar is wrong?

Cheers

[jdr_ni]

Hello,

This appears to be a bug with the Citadel database. The short-term workaround is to wait the extra minute before detaching the database. Shutting down the DSC Engine before attempting to detach the database should also work, if that is possible with your system.

Here�s a full explanation of the problem, if you�re interested. The Citadel database makes use of the Microsoft Desktop Engine (MSDE), a stripped-down version of SQL Server, to store alarm & event data. When you run the archive VI, the alarms are dumped into the Citadel database as raw binary data. This is very quick, which is why the status bar appears to be lying to you. The Citadel service then works in background to format the alarms into the MSDE tables, using a standard ADO connection
to talk with the MSDE server. When you try to detach the database, we close that ADO connection, but, as I�ve discovered today, ADO does not really close the connection immediately, but rather caches it in some sort of connection pool for later use. Now, if, as is often the case, that was our only open ADO connection, Citadel would cleanup its ADO resources which would close the connection for real, but, if the DSC Engine is still actively logging alarms, ADO stays open to handle the alarms from that database, and the connection does not get closed until some timeout occurs in the guts of ADO to flush the connection from the connection pool.

I have not been able to find a system setting which will disable ADO�s connection pooling. I will continue to investigate a more permanent solution to this issue, at which point a knowledgebase document will be added to this site.

J.D. Robertson
Software Engineer
National Instruments