|
Hi,
i'm working on an programe that reads several items from an MySql Database,
i've got the connection working. but for the last couple of days i've been struggeling.
I want to add items to the database via the use of 2 textbox but i'm cluesless on how to get the query,
i've been going over several pages tough all seem to fix on MMSql 2005 or on the connection string.
Any help would be greatly apriciated
Greetings
Ben
|
|
|
|
|
Any code that attempts to do this at the moment would be useful to see. It will help us point out where you're going wrong.
In the mean time, I suggest you read this great article here[^], specifically the section about parametrised queries. In short, you take the user's input and create a new MySqlParameter object from that information and perform an INSERT statement.
He who makes a beast out of himself gets rid of the pain of being a man
|
|
|
|
|
My coding for adding has been done,
Tought the removing function still does not , and i'm not sure how to finish the following:
string query = "DELETE FROM facturen WHERE Id = " there should be more here
MySql.Data.MySqlClient.MySqlCommand bQuery = new MySql.Data.MySqlClient.MySqlCommand(query, connection);
bQuery.ExecuteNonQuery();
connection.Close();
|
|
|
|
|
Hello everyone,
If all the Finalizer methods of all the used classes in a thread are programmed properly, means native resource are released in Finalizer (e.g. implementing Dispose pattern), no matter how the thread is terminated (normally, by Interrupt or by Abort or by Exit or ...), there should not be any resource leak, right?
thanks in advance,
George
|
|
|
|
|
|
Any more description please? 
regards,
George
|
|
|
|
|
I don't think that Abort gives the chance for a cleanup, unless you call ThreadAbortException. As for the Exit, when an application is terminating, I think the finalizer that are left to execute are not.
Put Trace statements in your Finalizers and Dispose methods to see.
In other words, if a class implements IDisposable, you should always call the Dispose method.
|
|
|
|
|
Thanks Le Centriste,
1.
Le Centriste wrote: In other words, if a class implements IDisposable, you should always call the Dispose method.
We can not alway have chances to call Dispose when unexpcted Abort is called on the thread, right?
2.
So, your point is there will be native resource leak when we call abort?
regards,
George
|
|
|
|
|
Usually, you should catch the ThreadAbortException in your thread. Read the remarks section of the following link:
http://msdn2.microsoft.com/en-us/library/ty8d3wta.aspx[^]
Your thread entry point should have a try/catch block, with special handling for ThreadAbortException.
Quick question: why do you need to call abort on your thread?
|
|
|
|
|
Thanks Le Centriste,
1.
You mean in the exception handler for ThreadAbortException, we should do clean-up things, like release the native resouce, or else there will be resource leak, right?
2.
Le Centriste wrote: Quick question: why do you need to call abort on your thread?
I am afraid others may call Thread.Abort on my thread, so I am asking how to handle properly. 
regards,
George
|
|
|
|
|
George_George wrote: You mean in the exception handler for ThreadAbortException, we should do clean-up things, like release the native resouce, or else there will be resource leak, right?
Yes, and if your thread is also prone to block, handle the ThreadInterruptedException also.
George_George wrote: I am afraid others may call Thread.Abort on my thread, so I am asking how to handle properly
That is very good thinking.
|
|
|
|
|
Thanks Le Centriste,
Le Centriste wrote: Yes, and if your thread is also prone to block, handle the ThreadInterruptedException also.
Either Abort or Interrupt is called, the Finalizers are not ensured to be called? I think if they are ensured to be called, we can rely on them to clean-up resources, and leave the body of handlers for Abort/Interrupt exceptions empty.
Any comments?
regards,
George
|
|
|
|
|
As a golden rule, you should always clean up behind you, and not rely on your mother to do it. 
Seriously, you could simply use the using statement, as finally blocks are always executed, no matter what. That will free you from having to handle the exceptions and still do the cleanup.
We should not rely on the Finalizers, as they are there as a last defense, and you don't know when they execute. Calling the Dispose method from a finally is a surefire way of cleaning up.
|
|
|
|
|
Thanks Le Centriste,
I am just wondering whether there are any official documents from Microsoft about whether finally block or Finalizer will be ensured to be called, when we call Interrupt or Abort on thethread?
Do you find such documents?
regards,
George
|
|
|
|
|
George_George wrote: I think if they are ensured to be called, we can rely on them to clean-up resources, and leave the body of handlers for Abort/Interrupt exceptions empty.
You can't rely on the finalisers to be called. When the objects are up for dispose, they will be placed in the queue for finalising. A background thread calls the Finalize method of the objects, but if there are too many objects left in the queue when the application ends, the objects will just be thrown away without finalising.
The ThreadAbortException exception exists so that you will have a chance to clean up the resources properly, so that you don't have to hope that they will eventually clean up themselves. You should clean up the resources as soon as possible, not wait for the garbage collector to initiate the cleanup.
If you create the IDisposable objects in using blocks, they will be disposed properly even if the thread is aborted.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Guffa wrote: A background thread calls the Finalize method of the objects, but if there are too many objects left in the queue when the application ends, the objects will just be thrown away without finalising.
Is the above scenario documented as a defined behavior for GC? I am confused. In my understanding, no matter how many objects need to get Finalize method called, they are all ensured to be called.
Do you have any documents to support your points that in some situations, the finalizers can not called?
2.
Guffa wrote: The ThreadAbortException exception exists so that you will have a chance to clean up the resources properly, so that you don't have to hope that they will eventually clean up themselves. You should clean up the resources as soon as possible, not wait for the garbage collector to initiate the cleanup.
Clean-up in the handler for ThreadAbortException?
regards,
George
|
|
|
|
|
George_George wrote: Do you have any documents to support your points that in some situations, the finalizers can not called?
"A stalled finalizer can prevent the CLR from completing the AppDomain tear down. To account for this, the CLR implements a timeout on this process, after which it will stop the finalization process."
Identify And Prevent Memory Leaks In Managed Code[^]
"Finalizers are expensive to run, and there’s no order (or even guarantee) that they will be run (for example, the finalizer thread may time out, or be killed on AppDomain unload)."
Demystifying Dispose[^]
"if the process is terminating, the system will timeout the finalizer thread if it cannot finalize all the items in a reasonable amount of time."
Critical finalizers (reliability part 1)[^]
".Net doesn't make any guarantee that the finalizer for each object will get called. In the current implementation .Net has one finalizer thread. If there exist a finalizer which block this thread then the other finalizer will never get called"
Memory Leak Detection in .Net[^]
George_George wrote: Clean-up in the handler for ThreadAbortException?
Yes, for anything that you can't use a using or try...finally to clean up.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
You are so knowledgable. Two more questions,
1.
Seems we can not rely on Finalizer when thread is Aborted.
Can we rely on finally block and exception handler for ThreadAbortException?
2.
Seems the timeout issue for Finalizer (Finalizer can not execute longer than some amount of time, as your referred article describes) only happens when AppDomain shuts down. If the AppDomain is still running, there should not be timeout issue?
regards,
George
|
|
|
|
|
George_George wrote: Can we rely on finally block and exception handler for ThreadAbortException?
A using block is the best way to ensure that objects are disposed. A try...finally works just as fine, assuming that you implement it correctly. The ThreadAbortException is sure to occur if the thread is aborted, but as it can happen anywhere in the code, it's a lot trickier to implement correctly.
George_George wrote: Seems the timeout issue for Finalizer (Finalizer can not execute longer than some amount of time, as your referred article describes) only happens when AppDomain shuts down. If the AppDomain is still running, there should not be timeout issue?
There could be, if one finaliser doesn't return. I'm not sure how the finilising thread handles this, but either it locks up, or it times out that specific finalisation after a while. Even if it has a timeout for every finalisation, it migh be busy for a very long time if there are a lot of instances of the same class, where the finaliser doesn't work.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Cool, Guffa!
I am just curious that why there is no documents which we could find that expected finally blocks and exception handler block are ensured to be executed during ThreadAbortException?
regards,
George
|
|
|
|
|
There is no specific documentation about this, because it's not handled any different than in any other code.
The only thing that is special is that the ThreadAbortException is thrown whenever the thread is aborted, and (AFAIK) that the exception doesn't cause a ThreadException in the application, if the thread doesn't catch it. Other than that, the situation is handled just as with any other exception.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
Suppose I have ThreadAbortException in a worker thread, the main thread could only catch it by using AppDomain.CurrentDomain.UnhandledException?
regards,
George
|
|
|
|
|
George_George wrote: Suppose I have ThreadAbortException in a worker thread, the main thread could only catch it by using AppDomain.CurrentDomain.UnhandledException?
Yes, that would be the only way of catching an exception from outside the thread. However, I don't think that a ThreadAbortException exception will cause that event to be triggered, but I can't find any documentation right now that either confirms or contradicts this.
A couple of clarifications/additions that I found while reading about the ThreadAbortException:
There is one more thing that is special about the ThreadAbortExcpetion; it will automatically be rethrown even when caught. So, it will trigger any matching catch all the way up the stack, unless Thread.ResetAbort is called to stop it from being rethrown.
The ThreadAbortException exception can be used by the thread to catch when the application is aborting the thread, but if a background thread is aborted because the application is ending, the exception will not be thrown.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Guffa wrote: Yes, that would be the only way of catching an exception from outside the thread. However, I don't think that a ThreadAbortException exception will cause that event to be triggered, but I can't find any documentation right now that either confirms or contradicts this.
I have verified you are correct. Here is my code. Could you review whether my code is correct please?
using System;
using System.Threading;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void ThreadProc()
{
Console.WriteLine("Begin sleeping ");
Thread.Sleep(5000);
Console.WriteLine("End sleeping ");
}
static void Foo(object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine("I am here ");
}
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(Foo);
Thread t = new Thread(Program.ThreadProc);
t.Start();
t.Abort();
return;
}
}
}
2.
Guffa wrote: but if a background thread is aborted because the application is ending, the exception will not be thrown.
Confused. You mean the ThreadAbortException will not be re-throw if it is caught?
regards,
George
|
|
|
|
|
George_George wrote: I have verified you are correct. Here is my code. Could you review whether my code is correct please?
Yes, that is correct as far as I can see.
George_George wrote: Confused. You mean the ThreadAbortException will not be re-throw if it is caught?
No, I mean that the ThreadAbortException will not be thrown at all. The background threads will just be stopped.
From the documentation of the Thead.IsBackground property:
"Once all foreground threads belonging to a process have terminated, the common language runtime ends the process. Any remaining background threads are stopped and do not complete."
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
