Arrr, It didn't do the trick.
I tried using executescaler instead and got the some error.
Also, I'm working with the ODP (I added the refference and the "using oracle.dataAccess.client") and with oracle 10g.
The problem is that I'm not even sure if the problem is from my C# code or from the oracle.
I know less about oracle so i took a very simple SP So there won't be any problem with that.
If You'll manage to get a result from a SP to a C# code I promise to add you to my holiday gift list
If the WriteToDoc class has a dispose method associated with it, you could do the following:
using (WriteToDoc writeToDoc = new WriteToDoc())
Dispose is automatically called when the execution block finishes.
If you don't have a Dispose method, just call writeToDoc = null to set it to a null value. Note that this isn't necessary because the garbage collector will pick it up some time after the variable goes out of scope.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
public void Dispose()
// This object will be cleaned up by the Dispose method.
// Therefore, you should call GC.SupressFinalize to
// take this object off the finalization queue
// and prevent finalization code for this object
// from executing a second time.
private void Dispose(bool disposing)
// Check to see if Dispose has already been called.
// If disposing equals true, dispose all managed
// and unmanaged resources.
// Dispose managed resources.
// Call the appropriate methods to clean up
// unmanaged resources here.
// If disposing is false,
// only the following code is executed.
//handle = IntPtr.Zero;
// Note disposing has been done.
disposed = true;
And in my Form i call the writeToDoc.Dispose() method like that.
For a class that is this simple, you really don't need a finalizer. Writing a proper finalizer is generally a non-trivial task as there are certain rules that need to be followed. Beyond that, adding a finalizer causes the runtime to place the object in the finalization queue when it is instantiated, which causes the garbage collection system additional work.
The finalizer will cause the Dispose method to be called if the coder forgets to call it, but that safety net usually comes at a higher cost than it's worth.
For a different view on how to implement the Disposable pattern, check out this article:
Having a Dispose method isn't enough by itself. Your class must implment IDisposable.
Well, "must" is not really true. Adding the IDisposable interface to the list of implemented interfaces for the class doesn't really make any difference. It doesn't change the implementation of the class in any way. Using the Dispose method works just fine without the interface, only you can't use the class in a using block as that requires the IDisposable interface.
It's just that the IDisposable interface is intended for this, so if you want to add disposability to a class in a well behaved way, you should implement the IDisposable interface.
The recommended way is to implement the IDisposable interface, but it certainly isn't required. Implementing the interface does allow the compiler to understand certain other conveniences, such as the using clause, but it doesn't cause any different compile-time or run-time behavior. It does, however, provide a valuable "clue" to anyone implementing the class that it has certain characteristics and expected behaviors.
For more information on implementing Dispose, check out the following article. It goes in to more detail than the MSDN docs and pulls together the information from some of the people that actually wrote the GC system.