I wrote an integration program that fetches data from an ERP and sends it to another program via a SOAP API.
In order to determine which data needs to be updated or created I'm also fetching the data from the SOAP API and building some custom early bound entities with that data using
records.AsParallel().ForAll(record =>
{
var acc = new Account(connection, record.name_value_list);
accountList.Add(acc);
});
Task.WaitAll();
I'va added the last instruction after having seen that the programs hangs upon completion and I have to close it manually (and it still lags 5-10 seconds when I do it).
I tried to add an additional wait condition in my Main as the last operation, but it does not help.
I debugged the app and in the Thread panel I see this:
How can I manage to exit my application gracefully?
I found the problem: I was retrieving the data from the ERP via a C++ DLL Api, but I was missing the closing of the connection at completion.
Once I did that the program closed correctly.
Windows Mobile 6.5
I have a process which uses System.Threading.Timer upload some data to net at specified intervals.
Now I want to terminate this process from a GUI application. I can use process enumerator to get Process object. What happens when I call Process.Kill? Does it jsut terminate it, the process could be in the middle of reading/deleting data from local database and sending it to service. What can I do make sure that atleast if its in middle it does not terminate and once it is done it can terminate before next Timer event fires?
Terminating an application like that cuts it off at the knees, introducing the distinct possibility of corrupting data. The only way around that is to not terminate the process.
You'll have to introduce a way to communicate to the application that it need to exit so that it can finish whatever it's doing so data won't be corrupted.
i.e. the application must be written in a way to accept a request like that (however you want to do it).
I am having a C# application to sync data between PC and palm devices.
There are codes written like below:
showMessage("synchronizing Table1");
Sync(destTable1,sourceTable1);
Sync(destTable2,sourceTable2);
showMessage("synchronizing Table2");
// more code
How do I separate the actual process of synchronizing from displaying message?
Which design pattern to follow?
Thanks in advance...
You should run the sync process on a separate thread and inform the main thread of the progress. The main thread displays messages.
You can obtain this behavior using the BackgroundWorker class that has all the feature ready.
I am calling a stored procedure from my application that can take 30 minutes to execute.
I don't want to make my user leave the application open for that entire time period. So I would like to call the sproc, let it fly, and let them shut down the application and come back later.
How can I do this?
This is actually a quite common scenario. You cannot do anything client based because the client may go away and disconnect and you'll lose the work achieved so far. The solution is to use Service Broker Activation: you create a service in the database and attach an activated procedure. In your application (or ASP page) you send a message to the service and embed the necessary parameters for your procedure. After your application commits, the message activates the service procedure. the service procedure reads the parameters from the message and invokes your procedure. since activation happens on a server thread unrelated to your original connection, this is reliable. In fact the server can even shutdown and restart while your procedure is being executed and the work will be rolled back then resumed, since the activating message will trigger again the service procedure after the restart.
Update
I have published the details of how to do this including sample code on my blog: Asynchronous procedure execution.
You can use the BeginExecuteXXX/EndExecuteXXX methods (depending whether it returns a result or not) of the SqlCommand, passing a callback delegate.
I suggest a re-architecture. Create a "work queue" table where you log requests to run the stored procedure. Then either have a Windows Service or a SQL Server job check that work queue from time to time (or be really ingenious and use a trigger) to kick off the stored procedure. Have the stored procedure update the progress from time to time in the work queue table, and your front-end can look at that an tell the user the progress, and then display the results when they're done.
If you really want to close down your application completely, I suggest you define a job in SQL Server Agent, and just execute a T-SQL statement to start that job manually. The syntax is:
sp_start_job
{ [#job_name =] 'job_name'
| [#job_id =] job_id }
[ , [#error_flag =] error_flag]
[ , [#server_name =] 'server_name']
[ , [#step_name =] 'step_name']
[ , [#output_flag =] output_flag]
The job would execute your stored procedure. You will have to be a little creative to pass in any arguments. For example, insert the parameters into a "queue" table and have the job process all the rows in the queue.
Instead of a job, an insert trigger on your queue should work as well.
I prefer to use a background service for offline processing, where your user app tells the service what to do and then disconnects. The service can log elapsed times and errors/status, and restart if necessary. WCF is designed for this and supports queues to communicate with.
let them shut down the app and come
back later
If you're going to allow them to completely close the app, you'll have to start up a seperate .exe or something in a different ThreadPool that executes your code calling the stored procedure. Otherwise your thread will die when you close the app.
Another method that you could do would be to allow your application to run in the background (possibly in the notification area) and then exit or notify when the job completes. You could use this by using the BeginExecuteNonQuery and EndExecuteNonQuery methods to allow it to run in a separate thread.
Your application's main window does not need to be open. If you launched it as a secondary thread, it will continue to run so long as IsBackground == false. I usually prefer to do this stuff through SQL Server Agent or as a client-server application (nothing prevents a client-server app from both running on the same machine, or even being the same binary).
It's been a while...
using System.Threading;
.....
Thread _t = null;
void StartProcedure()
{
_t = new Thread(new ThreadStart(this.StartProc));
_t.IsBackground = false;//If I remember correctly, this is the default value.
_t.Start();
}
bool ProcedureIsRunning
{
get { return _t.IsRunning; } //Maybe it's IsActive. Can't remember.
}
void StartProc(object param)
{
//your logic here.. could also do this as an anonymous method. Broke it out to keep it simple.
}
I need to install mysql in my system in the first step
After installing or modifying the mysql in the system , I need to the run the data base scripts.
The problem here is db scripts started running before mysql setup completes.
I have tried different ways.. using auto run methods...using processes etc
can anybody tell me how to capture the (child)process id which is invoked by the current process(parent). Here in my case parent is invoking child process and exiting.
System.Diagnostics.Process has a method WaitForExit.
Edit: To also watch for subprocesses, you can use Win32 Job objects. If you create a process in a job, all of its child processes will also belong to the job (unless someone explicitly detaches them). You can monitor the job for events such as process creation and termination. There is a C# wrapper for job objects, JobObjectWrapper.