@Ben wrote:
@iCat wrote:
According to my coworkers, citadel crashes when they try to read a lot of data from it.
I have at least one application (7 instances running another scheduled to be created) that has been collecting and logging 24 X 7 for about 10 years now. Yes it started with an older version as is currently running as a LV 8.2.1 version.
The 8.2 version ran good for a couple of years and then security actions by IT started resluting in complications like data going missing and corrupted DBs etc. Since I had multiple versions running I noticed that the LV 8.2.1 versions did not suffer but the 8.2 versions all were getting smacked.
Turns out there was an upgrade of the SQL server between 8.2 and 8.2.1.
All is quiet now.
But as to the crashing when fetching large amoutns of data...
The DB has to be managed, using backups and archieves. If the DB fetch return more records than can be stored in memory, you are going to run into problems regardless of who wrote the interface (you or NI).
So before I would rewrite the API I suggest you first look into the nature of the crashing and investigate management possibilities.
The solution may end up being as simple as adding more memory on the machine serving the DB.
That's my 2 cents,
Ben
My coworker said he fixed the crash problem, but there were other problems.
He consolidated two machines, and the tags were combined into one machine, too.
That increased the number of DSC tags written to citadel DB from 100 to 300.
He also had to configure citadel from the scratch.
After then, in HyperTrend Control, tag values aren't being fetched continuously but accumulate in memory for seconds before being shown to the client program.
It seems like a read cache to me. The client program receives tag data in big chunks instead of a small one.
How can he make the client program receive tag data in small chunks?
Did he forget to configure some security settings?
Or does he have to update citadel DB engine?
Is there anything else he needs to do?
