|
I am logging data from a USB device (pooling the device) using a timer component with C#.
Every 250ms (timer tick) I read the data from the device and save it to a CSV (coma separated value) file.
I just thought I should ask if there is anyway to improve on the saving of the file. I am new to C#/.net so would really like a review of the idea.
1. Every timer tick I read two values from an object (the USB device interface).
2. Open the file by creating a Steame writer object;
StreamWrite out = new StreamWriter(filename, true).
3.Write the values to the file
out.Writeline("{0},{1}",value1,value2);
4.Close the file.
out.close();
The main question is should I keep opening and closing the file every tick or should I open it when the logging starts and close it when the user stops the logging of the data? The reason I close the file is so if the application fails I do not lose any data.( the file is being used only by this application).
Any comments to improve the code will be useful.
Thanks cages
|
|
|
|
|
Can't compute. What kind of data is it? How does it evolve over time? Why are you doing this?
|
|
|
|
|
The data are double values that represent temperature(the usb device is a teperature logger).
The data will be logged for about 3 hours.
|
|
|
|
|
OK. If getting maximum probability of getting all the data is paramount (say your USB is used while debugging a system that eventually crashes), then yes keep the file closed as much as possible. I do this while logging any application during its development, and that takes hundreds of text lines per second! (Of course your USB access might slow down things a bit, depending on the device).
The easiest and cheapest way probably is by calculating a single string (including the NewLine terminators) first (string.Format() may be useful here), then calling File.AppendAllText().
|
|
|
|
|
Ummm... how much can the temperature change during so short a time period?
First; yes, open and close each time you write to the log.
But, you shouldn't keep writing needless repetitive data. My first professional programming job involved polling some equipment for temperature and such and then passing it to a specialized database system. The database didn't simply store everything my software sent; it tested the incoming data and made a determination as to whether or not it was significant. Each datum could be configured as to what was significant -- for instance if a temperature changed by a one-hundredth of a degree; or if a value hadn't been stored for some period of time (perhaps ten minutes). This greatly reduced the amount of data stored and sped up reporting without losing significant detail.
I strongly suggest you implement a similar technique.
|
|
|
|
|
Option 3. Use a logging framework such as log4net where somebody else has taken care of the development and testing of this for you.
|
|
|
|
|
I have an application in C# made by me, is something like a database with clients for a hotel, and every client has a report, with informations stored in an mysql database. I want to print that report on printer, and I don't know exacly how. I need something like a template and only some fileds to be completed with the informations. I'm working with mysql and VS 2010
|
|
|
|
|
This[^] article is a fairly comprehensive run through of printing from C#. If you work through it, you will get the idea.
As far as reports are concerned you could use Crystal Reports, if it came with your version of Visual Studio. There is also the ReportViewer control although, without checking, I do not know if it works with MySql.
Alternatively you could try using something like "Report Definition Language", as described in this[^] article from The Code Project.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
|
Hi all,
This is not so much a technical question but rather to get the opinion of others with regards to a solution I require.
For the sake of simplicity, lets say I have a database table will a list of scheduled emails - this table contains a schedule date/time and the content of the email to send. These scheduled emails can be created, modified and delete at any time.
My initial thoughts on achieving this is to create a Windows Service (I think this is better than a IIS hosted WCF Service because of the need for timers - maybe I am wrong?). This service will then query the DB table at regular intervals and send any emails that need sending.
But how best to handle the timing? I want the scheduled emails to be sent as close to the correct scheduled time as possible but at the same time I want to limit the querying of the DB (i.e. not every second)
I also thought about notifying the service when a new task is scheduled and then setting a timer up there and then based on the difference between current time and scheduled time. This however may lose precision. Also, what if a scheduled email is modified/deleted? Also, doesn't seem best for schedules of a long time (e.g. a day, a week or a month even)
Any opinions are welcome
Thanks
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
I wrote an article about scheduling: I have used the code a few times in windows services. As far as reducing queries on the database, you can schedule that too.
Scheduling Future Dates [^]
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Thanks for your reply and an interesting idea. Which I guess in your suggestion would be to sleep a synchronous thread until the task is due to run.
I guess my issue here would be when tasks are changed or cancelled. I suppose I could check the task is still valid at the same time you are comparing the dates. But then if I need to re-query the DB I may as well do so at regular intervals. I am not sure I like the idea of sleeping a thread for a week especially one that will be dynamically created.
I have been thinking that scheduled intervals will be limited to every 15 mins (e.g. 12.00, 12:15, 12:30 etc.) - So I could get away with querying the DB every 15 mins (or just short of and sleeping) - that way I can make sure I don't miss new tasks and updated tasks and I don't even need to notify the service when a tasks is added/changed
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
If the schedule changes, you can destroy the current timer thread, and start a new one, or design your threads in such a way as to be able to compensate for said changes. It's a simple matter of implementation.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
But then I have the extra effort of needing to track all timers and the application creating the the tasks would need to notify the service of changes. I just don't think it needs to get so complicated for what is really quite a simple concept.
I do like your suggestion in terms of maintaining precision, I just don't think its right for my needs. Effectively what I would end up doing is creating an in-memory copy of the database table (or at least a cut down version of) in order to identify timers - thou I guess I would only need the ID column values linked to the timers.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
if you get the mails-to-be-sent from the database sorted by datetime ascending, your app (Win Service) can send the ones it considers "immediate", then delay itself till the time arrives that corresponds to the first one that hasn't been sent yet. The only caveat is there could be new requests added while your service is asleep.
|
|
|
|
|
Thanks for the reply.
Yes, it is almost certain that new ones will be added while the service sleeps - this is why I was thinking of limiting the scheduled intervals to 15 minutes and querying the DB every 14.9 minutes in anticipation.
On a second thought, what if on first run of the service there are no tasks to be processed? I would definitely need to query regularly in that case.
Wouldn't it be nice if there was a system event you could hook up by specifying the date/time you wanted it to fire, like...
System.Schedule.FireAt(ProcessFunction, DateTime.Laters);
...thou I would still need to validate the task, and on seconds thoughts, that's pretty much what a timer does 
So, query every 15 mins? See any flaws?
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
If the data changes, you basically have three options:
1.
only allow changes through your web service itself, so it knows at all times what is going on.
2.
organize your database so it provides events to your web service; the possibilities will depend on your DB. And I can't help you out here.
3.
implement a polling scheme, i.e. have your web service query the DB regularly.
Depending on the exact needs you may prefer to have a mix of the above.
|
|
|
|
|
Thanks Luc,
I am starting to implement 3 but 1 is something I hadn't thought of - thou I would have to rely on the database not being tampered with from other sources which I don't like the thought of
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
You're welcome.
|
|
|
|
|
A step to remedying the issue of someone updating the table from outside your application is to add INSERT or UPDATE triggers on that table. The stored procedure can send a pipe message or email to wake up your monitoring thread to amend it's plan. I've used similar techniques for situations in which multiple events need to be accommodated; in your case it's:
1) New email added to the queue with a send time earlier than the earliest current one
2) Message from SQL Server to alert of a change in the queue table (via SMTP or named pipe)
3) Trigger time to send the first email(s) out
It sounds complicated, but the implementation isn't actually all that difficult. And it's a handy tool to have in your arsenal for future situations.
|
|
|
|
|
Well, do you really want your service to work with data in the database that has been tampered with?
Depending on the number of scheduled emails (due to memory constraints), you could have the service be the sole keeper of the email information - and only write to the database as a backup store. Then you have much more control over the process - the service gets and tracks the requests - if it is caching to the database (or other store), then it can control how long in the future to cache, and so will know when to pull from the db again. (Imminent tasks can also be stored in the db for failover purposes, but won't have to be looked up unless the service is restarted for some reason).
|
|
|
|
|
I implemented a scheduling feature in our application server, it works with a thread wich calculates the amount of time to sleep until the next action. If a new action is added, the thread is interrupted and it computes a new wake up delay.
|
|
|
|
|
What about getting SQL Server agent to do the scheduling? It's rather good at this. That way, you could create a job to run every minute say which just runs the query and appends the new emails to a queue table. Because all that's in the database domain you can make it transactionally safe etc, and should your windows service go down, you'll have everything queued up when it comes back up.
Then, you can poll your queue table quite frequently (say every second) because most of the time its going to be empty.
Just a thought.
Regards,
Rob Philpott.
|
|
|
|
|
Thanks. I see your logic but perhaps this is a flaw in my simplified requirements. The actual tasks that are going to run are not just emails being sent but the service will process other DB data and provide that information like an export function.
But I like your idea in terms creating a queue table, I will try to keep that in mind if the need arises
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
musefan wrote: other DB data and provide that information like an export function.
Actually you can do the entire operation within the (SQL Server/Oracle) database, including send the emails. This is how it used to be done before these new fangled service thingys turned up. SQL jobs have fallen out of favour in the last few years but the DB has a long history of doing this precise operation.
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
