Thanks for your reply Roger,
There is an issue on retrieval of data and basically this issue is how an operating system works with files and how you are using them.
Your data is kept in a file on a virtual hard disk inside the dataTaker. Now to maintain data integrity only one process at a time can access a file. Imagine if you were trying to find a page in a document while some one was adding in pages and someone else was deleting them, the job becomes very complex and could quickly get out of hand.
I agree about the necessity of letting only one process at a time
modify a document, but I can't see that there should be any problem
with having one process reading data while an other are appending
data at the end of the file.
Since the datakare 800 is a modern real time measurement device, I think that problems like this should have been taken care of.
Keep the files as small as possible. The smaller the file the less there is to search so the search time is reduced.
What would be the best way of implementing this, there is no
CLAST command as in the DT50?
Don't use the logger to store historical data. You say that sometimes you must unload data from old jobs, it would be far better to keep old data in a computer database and use that to search the data off line. This would free up the dataTaker to concentrate on logging data.
We do indeed keep our historical data in a database. The reason for
reading old jobs is
When the configuration on a logger changes, enable or disabling of a sensor, changing the log rate for a sensor (we use different schedules for each log rate, so changing log rate means that we use a different schedule for that sensor => a new job is created)
Some loggers are not always online (connected by radio or phone modem). When the logger comes online again, the job in the logger may
have been changed by a local operator. This is detected by the retrieval program and data from the previous job are requested.
I agree that we have a complex set-up for our logging system, some logger are connected directly on the Ethernet, some by radio modems and others are used standalone and emptied on a portable computer. When we evaluated loggers for the system we were impressed by the datataker documentation, the amount of commands available etc.
I have not found any trace of warnings that the logger can't log data at same time as retrieving old data.
Bertil
Thanks for your reply Roger,
> There is an issue on retrieval of data and basically this issue is how an operating system works with files and how you are using them.
> Your data is kept in a file on a virtual hard disk inside the dataTaker. Now to maintain data integrity only one process at a time can access a file. Imagine if you were trying to find a page in a document while some one was adding in pages and someone else was deleting them, the job becomes very complex and could quickly get out of hand.
I agree about the necessity of letting only one process at a time
modify a document, but I can't see that there should be any problem
with having one process reading data while an other are appending
data at the end of the file.
Since the datakare 800 is a modern real time measurement device, I think that problems like this should have been taken care of.
> Keep the files as small as possible. The smaller the file the less there is to search so the search time is reduced.
What would be the best way of implementing this, there is no
CLAST command as in the DT50?
> Don't use the logger to store historical data. You say that sometimes you must unload data from old jobs, it would be far better to keep old data in a computer database and use that to search the data off line. This would free up the dataTaker to concentrate on logging data.
We do indeed keep our historical data in a database. The reason for
reading old jobs is
1. When the configuration on a logger changes, enable or disabling of a sensor, changing the log rate for a sensor (we use different schedules for each log rate, so changing log rate means that we use a different schedule for that sensor => a new job is created)
2. Some loggers are not always online (connected by radio or phone modem). When the logger comes online again, the job in the logger may
have been changed by a local operator. This is detected by the retrieval program and data from the previous job are requested.
I agree that we have a complex set-up for our logging system, some logger are connected directly on the Ethernet, some by radio modems and others are used standalone and emptied on a portable computer. When we evaluated loggers for the system we were impressed by the datataker documentation, the amount of commands available etc.
I have not found any trace of warnings that the logger can't log data at same time as retrieving old data.
Bertil
