![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Connectivity » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Fri, Feb 13 2009 12:16 PM | Permanent Link |
"Hedley Muscroft" | Hi Tim. The EDB SQL help file says :-
"Since the ElevateDB .NET Data Provider is indirectly accessing and using unmanaged resources during operation, you should always call the Dispose method for any EDBConnection, EDBCommand, EDBCommandBuilder, or EDBDataAdapter objects when you are done using them (deterministic destruction). Failure to do so can cause major failures in the data provider due to the resources being freed up re-entrantly when the .NET garbage collector thread finalizes these objects." I understand the need to close/dispose of an EDBConnection objects - especially in a C/S environment, although as per an earlier post you mentioned that for a desktop app, simply maintaining one global open connection object should be fine for EDB in LOCAL mode. I am introducing EDB to a project which can already run with PGSQL and DBISAM backends via DevArt's PGSQL ADO.NET provider and ContextSoft's DBISAM provider. I have managed to change my app so that it now only maintains one global EDBConnection object which gets passed to all other ADO objects (EDBDataAdapter, EDBCommandBuilder etc.). In other words, these other objects will always use the global EDBConnection rather than creating their own. That being the case, is it still essential to be call Dispose? I'm really hoping the answer is no! The reason is that I have a "Data Objects" layer in the application. Each "Data Object" (DO) is basically a wrapper around a record in a table and each DO has a DataAdapter at its core. The Data Objects can be passed around the application (e.g. from form to form) and basically are allowed to drop out of scope when they're no longer referenced by any forms or other. This design obviously means that we can't always call .Dispose on the DOs. At present, the application runs happily with PGSQL and DBISAM and there's no obvious memory bloating or leaking even though these DataAdapters are NOT being explicitly disposed. Is this going to be a problem for EDB? Any input would be greatly appreciated! Many thanks, Hedley |
Fri, Feb 13 2009 2:37 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Hedley,
<< That being the case, is it still essential to be call Dispose? >> Yes, you should definitely call Dispose for the EDBConnection before the application shuts down so that ElevateDB has an opportunity to release all unmanaged resources from within the thread in which they were allocated. << I'm really hoping the answer is no! The reason is that I have a "Data Objects" layer in the application. Each "Data Object" (DO) is basically a wrapper around a record in a table and each DO has a DataAdapter at its core. The Data Objects can be passed around the application (e.g. from form to form) and basically are allowed to drop out of scope when they're no longer referenced by any forms or other. This design obviously means that we can't always call .Dispose on the DOs. At present, the application runs happily with PGSQL and DBISAM and there's no obvious memory bloating or leaking even though these DataAdapters are NOT being explicitly disposed. Is this going to be a problem for EDB? >> You may be able to get away with this in an application, but the bottom line is that you need to dispose of any objects that are allocating unmanaged resources, or else you will possibly see random locking and file I/O errors in your application. Again, the reason for this is that the ElevateDB .NET data provider is directly accessing these unmanaged resources, i.e. there is no database server doing this for it, when you are running it with local, not remote, EDBConnections. Both of the .NET data providers that you mention above are not allocating or using any local unmanaged resources, therefore they don't require the Dispose calls. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 13 2009 10:29 PM | Permanent Link |
"James Relyea" | It's always a best practice for .Net to always call the dispose method for
any object that has 1. Another best practice is to use the USING statement because it ensures proper object disposal even when a try...catch captures an exception. Could this have any benefit to you? Rather than passing DataAdapters around your forms, create a class and keep them there. Simply create a reference to your DA class and call them? I've been using TableAdapters for a while now (intro'd in .Net 2.0, and I don't know your version) which save quite a bit of coding. ElevateDB works quite well with TableAdapters by the way. With the 2.02b B7, you'll have to remove the quotes from any stored proc names in the TableAdapter commands. The select command will auto build your datatable. Params get created automatically, plus you can have multiple selects for a dataset. That's my 2 cents ![]() ![]() jr "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:DA5593AD-5F0C-49CF-84F5-C9AB39D98BC3@news.elevatesoft.com... > Hedley, > > << That being the case, is it still essential to be call Dispose? >> > > Yes, you should definitely call Dispose for the EDBConnection before the > application shuts down so that ElevateDB has an opportunity to release all > unmanaged resources from within the thread in which they were allocated. > > << I'm really hoping the answer is no! The reason is that I have a "Data > Objects" layer in the application. Each "Data Object" (DO) is basically a > wrapper around a record in a table and each DO has a DataAdapter at its > core. The Data Objects can be passed around the application (e.g. from > form to form) and basically are allowed to drop out of scope when they're > no longer referenced by any forms or other. This design obviously means > that we can't always call .Dispose on the DOs. > > At present, the application runs happily with PGSQL and DBISAM and there's > no obvious memory bloating or leaking even though these DataAdapters are > NOT being explicitly disposed. Is this going to be a problem for EDB? >> > > You may be able to get away with this in an application, but the bottom > line is that you need to dispose of any objects that are allocating > unmanaged resources, or else you will possibly see random locking and file > I/O errors in your application. Again, the reason for this is that the > ElevateDB .NET data provider is directly accessing these unmanaged > resources, i.e. there is no database server doing this for it, when you > are running it with local, not remote, EDBConnections. Both of the .NET > data providers that you mention above are not allocating or using any > local unmanaged resources, therefore they don't require the Dispose calls. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Sat, Feb 14 2009 2:03 AM | Permanent Link |
"Hedley Muscroft" | Hi Tim,
>> you should definitely call Dispose for the EDBConnection Yes, in ADO.NET deterministic destruction of any DbConnection descendant is vital (which I always do), but I was more interested in the EDBDataAdapter, EDBCommand and EDBCommandBuilder objects. >> you need to dispose of any objects that are allocating unmanaged >> resources... ElevateDB .NET data provider is directly accessing >> these unmanaged resources I guess my question should have been :- Which of the EDBXxxxx data objects specifically allocate and access unmanaged resources? Obviously the EDBConnection, but do the other 3 mentioned above? Wouldn't all unmanaged resource allocation go via EDBConnection? Or is it perhaps the case that EDBConnection depends on the other classes to be Disposed so that it can release resources? Sorry for my ignorance Tim - I'm just wanting to make sure before I have to start hunting down 100s of data-adapters in my code! ![]() Thanks. |
Sat, Feb 14 2009 2:09 AM | Permanent Link |
"Hedley Muscroft" | Hi James,
Thanks for your input. >> Rather than passing DataAdapters around your forms, create >> a class and keep them there. Simply create a reference to your DA class >> and call them? I came to the same conclusion and started coding a DataAdapter factory class to separate the adapters from my DataObjects. It will be more efficient anyway and will mean I can make sure they all get disposed correctly. Many thanks. |
Sat, Feb 14 2009 8:53 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Hedley,
<< Which of the EDBXxxxx data objects specifically allocate and access unmanaged resources? >> Always assume that all of them do, since they may in the future even if they don't now. << Wouldn't all unmanaged resource allocation go via EDBConnection? >> No, unmanaged resources include things like file handles, critical sections, etc. Basically just about any object allocated via the Windows API through the .NET framework. The ElevateDB engine uses these throughout its codebase. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |