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

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

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
>

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.

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.

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