DataAccessAdapter Is disposed..

Posts   
 
    
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 23-Oct-2009 00:07:35   

Hello

I was wondering if there was a way or property that I could tell from whether or not a DataAccessAdapter has been disposed? For example:

DataAccessAdapter adapter = new DataAccessAdapter();

using (adapter) {

  // do something like fetch entity

}

Now adapter has been disposed - what I need is way to check and see if it has been disposed before using it again..

For example(I know this doesn't exist but you get the idea)

if (!adapter.IsDisposed) { // do something like else fetch another entity } else {

adapter = new DataAccessAdapter();  

// do something like else fetch another entity }

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 23-Oct-2009 04:29:10   

There is an _isDispose variable on DataAccessAdapter class but it's private. What you can do is create a partial class for your adapter and then override this method:

protected override void Dispose(bool isDisposing)
{
    // ..... your code

    // call the base
    base.Dispose(isDisposing);
}

In ".... your code" you could update some variable (your custom variable). In general this is not necessary. I encourage you to create a new DataAccessAdapter object in each method, or context, so it will get disposed by itself.

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 23-Oct-2009 10:23:58   

why the 'using' statement, if you don't want to consistently dispose it? please use this rule: - create the adapter when you need it, the creation of an adapter is very cheap (almost instantly) - create it INSIDE the using statement (e.g.: using(DataAccessAdapter adapter = new DataAccessAdapter) - do you data access calls inside the using statement.

Frans Bouma | Lead developer LLBLGen Pro
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 23-Oct-2009 17:33:50   

Well - I guess I look like an idiot with the sample code I put in my original question - it was only to show what I meant by my original question of "Is there a method or property that one can access that will flag if a DataAccessAdapter has been disposed?" Apparently, there isn't. In my humble opinion, I think there should be as I'm sure there are times when one's code might need to check this condition to avoid run time errors..

Anyway - thanks again for your input and support

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 23-Oct-2009 18:38:18   

Stoop wrote:

Well - I guess I look like an idiot with the sample code I put in my original question - it was only to show what I meant by my original question of "Is there a method or property that one can access that will flag if a DataAccessAdapter has been disposed?" Apparently, there isn't. In my humble opinion, I think there should be as I'm sure there are times when one's code might need to check this condition to avoid run time errors..

Anyway - thanks again for your input and support

I understand the question, at times I also wonder if a given control / class is disposed, but actually, when you ask that question, do realize that the check is actually not allowed: if an object is disposed, it can't be used in any expression whatsoever: the internals are no longer accessible.

So when you NEED the knowledge if an object is disposed or not, it's actually better to rethink the design, as either: you use a global object which shouldn't be disposed (or only once) or you only use local objects and you don't need the flag.

With the adapter, it's best to use local objects only, so never create a global adapter and share that, unless you need to pass it on to methods which have to share the same transaction: in that situation, you still dispose at the spot where the object is created, the starter of the transaction.

Hope this helps a bit simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 23-Oct-2009 20:25:40   

Good points, Otis, well put. Sometimes I am guilty (And I'm assuming we all are from time time) of "tunnel vision" and forgetting to step back and look at the big picture..

Thank you for pointing this out..