By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,905 Members | 2,075 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,905 IT Pros & Developers. It's quick & easy.

Need programming help

100+
P: 153
IT"S A LONG QUESTION.PLEASE BE PATIENT TO READ IT.
I HAVE EXPLAINED IT TO MY MAXIMUM CAPACITY.

I am making one app. in which i need to create a seperate access database for each day.

Its a call charging software which monitors the calls made by extensions (just like the hotel rooms).

Now there is GUI, in which there is richtextbox, a treview, and a menustrip.

The treeview shows information about the all the extensions and others.
The user when opens the app can see the treeview on left,richtextbox at bottom and menustrip (at top).

The user can change the nodes when required(and correspondingly the changes are commited to the database)

There is also one "start" button which starts the monitoring.
Now the user can ONLY see the treeview,expand the nodes and scroll the richtextbox when the app. is monitoring (when the start button is clicked) .

They cant change the nodes while the app is monitoring.

For changing they will have to stop it, so that the GUI thread becomes free for not-so-important thing:changing the nodes text (and database)etc because :

There is one serial port component(created at GUI thread) which monitors incoming strings and fetch the data(duration,date,extno. and blah blah) which is very imp (it cant miss even a single incoming string !)

What i am doing is, when the event Data_received of the serial port fires , i create a seperate thread and pass the string as argument(so that the details of teh calls made can be saved in database) so that the GUI thread becomes free and can handle the next incoming string.
Also, the data is stored in a file whose name is same as the day(12/04/08)
I have two main questions :

(1) HOW would I manage the seperate access file for each day?
I can do this:
a)When the app runs for the first time verify that that the database for current day is created or not.(if no create one.)
b)create a thread called DatabaseCreator, which is like this

Expand|Select|Wrap|Line Numbers
  1. while(true)
  2. {
  3. If(today's database not exists)
  4.      create one;
  5. }
but this will be a wastage of thread, so i need more efficient solution.
Why i am so desperate the create the database is coz the serial port in GUI thread wants to store the details in today's database !I If it does not find one it will wait till it becoems available (waiting means the next string wont get processed or will be in Queue which i dotn want)
SO this wont work
Expand|Select|Wrap|Line Numbers
  1. while(true)
  2. {
  3. If(today's database not exists)
  4.      create one;
  5. else
  6. Thread.sleep(one hour or so)
  7. /*oops the datareceived cant find the databse for today it's 12:00:01 midnight ! And  I last woke up at 11:50 and again slept.I will wake up at 12:50 to check(12:00:00 to 12:50:00 data not stored !)*/
  8. }
(2) WILL the expansion and collapse-ation , maximisign and minimising of the app will create fa problem for dataReceived event coz the event will be fired in GUI thread??

Thanks for ur patience to read it.
Jan 15 '09 #1
Share this Question
Share on Google+
3 Replies


vekipeki
Expert 100+
P: 229
Hi!

First of all, there is one question which pops out immediately: Why do you want to make a new Access file every day? The point of having a database is to have it all in one place, so that, by making queries, one can easily extract and filter the information he needs.

Presuming there is a valid reason for this, this is what you can do:

1. To create an Access database in C#, you can use the ADO Ext. library: How to create an Access database by using ADOX and Visual C# .NET.

2. Why can't you just create your file when handling SerialPort.DataReceived? When the event is triggered, check if the file exists and create it if needed. You should avoid using "while (true)" constructs or and Sleep(time) in a loop, since there are usually better ways of triggering code (timers, events, semaphores etc.)

3. If you cannot or don't want to create a file when handling SerialPort.DataReceived, you can queue your messages together with a time stamp in DataReceived handler ("producer" thread), and handle the complete queue in a different thread ("consumer" thread). Google it (this is an example of producer/consumer: How to: Synchronize a Producer and a Consumer Thread (C# Programming Guide)). Note that handling the data immediately (2.) is still the simplest way, so find a good reason to skip it before going for multithreading.

4. If you are talking about SerialPort.DataReceived event, that event is never fired from the GUI thread. SerialPort has a different thread internally which fires that event. It also has an internal buffer so that it can run asynchronously (received bytes are queued to this buffer from the driver's buffer in a separate thread).

Having that in mind, note that you won't be able to update the GUI while handling the DataReceived event without getting the Cross-thread exception, but you didn't mention that for now, so I presume you are not updating anything in that event.
Jan 15 '09 #2

100+
P: 153
Thanks vekipeki !

(1)
You asked me why should i create a seperate access file for each day.
You see if I create a single file for storing the details of all the calls it would get full sooner or later causing my application to crash.
I know that the calls made in one day can no way fill up the access file created for that day but this way I can see on the safe side.

I had thought that while searching so many access files I would do this

while(file !=null)
{
execute the query corresponding to this file
fill it in the datagrid

move the file pointer to next file
}

Although this is not the most efficient thing but atleast It will protect my program from getting crashed.

(2)
Also. i will just embed a blank ms access database file with my ap and just copy it to the application folder and renaming to that day's name.

(3)
You said that the DataReceived event will get fired on a seperate thread and the messages get buffered , so no messages will be lost.
That sentence made me really happy :)

(4)
You asked why dont I check the presence of file during DataReceived event.
I thought that it will create unnecessary headache for the event and that because of this checking-for-presence and creating-if-not-present thing will make my application lose some of the strings.
But after u told me that the strings get buffered, this should not be a big problem and i will implement what you said.


(5)

I wanted to leave access and go for more robust Sql server Express but it's installation is the problem.I guess it would be too diff. for them to install it attach the database, set the connection string in app.config.
So i went for Access.

Can u sugest anything better than this ?

THANKS A LOT vekipeki
Jan 15 '09 #3

vekipeki
Expert 100+
P: 229
Note however that serial port buffers are limited, so handling an event with a large baud rate and continuous incoming data means that you should nevertheless take care that you don't waste too much time in your handler.

If you create your database once a day, then it shouldn't worry you too much, but the safest way (although harder to implement) in any case would be using producer/consumer threads. In that case event handler would simply update the queue and end the DataReceived thread immediately. If you have enought time to implement it, you will get a piece of code that is reusable in other apps regardless of their baud rates or processing amounts.

Moving to SQL server would be easier if your Access database were in a single file, meaning you would then only change your data layer slightly. There are some articles about SQL server deployment (e.g. CodeGuru: Deploy SQL Databases Easily with the Installer Class) that might help you if you decide to go in that direction.
Jan 16 '09 #4

Post your reply

Sign in to post your reply or Sign up for a free account.