Trace Disappears When Engine Is Running (as seen from ODBC driver)

[josborne]

I have been able to reproduce a very strange problem ivolving DSC and the Citadel ODBC driver. Here's the skinny:

I am running LV DSC on a remote PC. It is logging a bunch of tags. One of the tags is logging at a relatively high frequency (250 Hz). I have a VI-based server to log these points.

I am then using Microsoft Query to retrieve data from the remote Citadel database via ODBC.

When you first connect to the Citadle database, Query presents you with a list of all the traces in the Citadel DB. If the DSCEngine is NOT running(on the remote machine) then I will get a complete list of all the traces as I normally should. I can query a trace and retrieve the data without any problems, for ex
ample:

SELECT LocalTime,"\\test2000\LabVIEW\HR" FROM Traces WHERE LocalTime > '11/13/2001'

HOWEVER, when the DSCEngine is running, the "high frequency" tag (250 Hz) does NOT appear in the trace list and MS Query returns an error "Unable to open trace \\machinename\LabVIEW\tagname".

This problem only occurs with the "high frequnecy" tag and only when the engine is running. It also does NOT occur when I use LabVIEW DSC VIs to retrieve the trend (Read Historical Trend.vi).

I am using the latest LOGOS files (4.4.0.12).

I know the problem is not with Microsoft Query because I can reproduce the same behaviour using other ODBC clients. We have a VB application that uses ODBC to retrieve data from Citadel and it reports the same behaviour ("Unable to open trace ...").

The trace just disappears from Citadel when the Engine is running! Help!

It might be kind of tough for me to attach the files you'd need to reproduce this problem. You'll need a lot of files (a simulati
on program to generate data for DSC, a VI Based Server to log it to Citadel and the SCF file). I might upload these files if someone at NI has the time to look at it?

[Martin_S.]

John,

Frankly there is no definite answer to this. It needs to be reproduced and explained... But if I was the one that is supposed to troubleshoot it I would try the historical VIs.

There are two that list the trace names - Get Historical Tag List and Get Trace Names. This would rule out the ODBC driver. Also each of them is using a different method to get the trace names. If these VIs can do it, I would run the Get Trace Info vi on the trace. The trace might appear empty, which is sometimes cause for Unable to open trace.

Timeout?
Another one is to watch for the amount of time it needs to open the trace. It could be that the ODBC driver is just running out of time to open the trace(?) when the engine is heavily streaming to it. CPU Usage at that time?


Dr. Tag

[josborne]

Thanks for the tips, Dr. Tag.

One more thing I forgot to mentions (just for the record) this problem I have disappearing traces only occurs after the database has grown for a few hours. When the DSCEngine is first run, and the Citadel database is created, I don't have any trouble using the ODBC driver... but after the database has grown a bit, and the engine is running, the "high frequency" trace disappears according to the ODBC driver.

[Martin_S.]

John,

I assume it is not enough to restart the engine/service or even computer(?). You have to delete the database to recover(?). If that's the case, then it could be the timeout issue. The fact that there is too much data associated with the trace. I recommend checking the # of metablocks and pages in MAX, just to get an idea of the trace size. Again, what is the CPU usage?

Dr. Tag.

[josborne]

More info:

NI has confirmed that they can reproduce this issue with the ODBC driver.

Traces begin to disappear after the database has grown to a very large size (Gigabytes). The guys in R&D are looking into it. I'll post more info as I hear from them.