LLBLGen Pro version: 2.6 Final (September 12th, 2008 ) SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll version: 2.6.08.0911

Since we changed from LLBLGen Pro version 2.0 to version 2.6 a System.ObjectDisposedException is thrown on any call of FetchEntity (see stack trace below). Are there any changes relating this behaviour between version 2.0 and 2.6? We only regenrated the code with LLBLGen Pro 2.6 and didn't made any changes to our code. The Dispose method of DataAccessAdapter is not called through our code.

Stack trace ---------------------------------------------------------------------------------

bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.OpenConnection() bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.PrepareQueryExecution(IQuery queryToExecute, Boolean forceConnectionSet) bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.ExecuteSingleRowRetrievalQuery(IRetrievalQuery queryToExecute, IEntityFields2 fieldsToFill, IFieldPersistenceInfo[] fieldsPersistenceInfo) bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntityFields2 fieldsToFetch, IFieldPersistenceInfo[] persistenceInfos, IRelationPredicateBucket filter) bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, IRelationPredicateBucket filter, ExcludeIncludeFieldsList excludedIncludedFields) bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, ExcludeIncludeFieldsList excludedIncludedFields) bei SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch)

Please post a code snippet.

Hint: After using the Adapter, set it to null. (after disposing it).

The following code snippet is called several times without an exception first and then the exception is thrown. Because the project is very complex i cannot post more code here. After disposing the DataAdapter the reference is set to null.

private DataAccessAdapter m_InnerDataAdapter;

public override void LoadData(object data) { m_InnerDataAdapter.FetchEntity((IEntity2)data); //exception is thrown here }

If the refernce was set to null after disposing the adapter, please try the following:

public override void LoadData(object data)
{
    if(m_InnerDataAdapter == null)
    {
        m_InnerDataAdapter = new DataAccessAdapter();
    }
    m_InnerDataAdapter.FetchEntity((IEntity2)data); //exception is thrown here
}

Unfortunately that doesn't work, since the Dispose method in our code is never called. Disposing must happen internally in the DataAccessAdapter. As previously mentioned we didn't change our code between the LLBLGen Pro version 2.0 and 2.6. With version 2.0 everything works fine. Were there any changes since version 2.0 concerning disposing?

V2.0 had different code flow for this code path than v2.6

Do you share the adapter among threads? Do you use 'using' statements somewhere? If you ALWAYS use: using(DataAccessAdapter adapter = new ... ) { // do db actions here } // dispose call happens here

you will have no problem. If you store the adapter in some member variable which might be ran by multiple threads (websites) you might run into this, or if you somewhere use a using block somewhere, it's disposed by the using block. Your error seems to come from the fact that a connection object was closed and therefore disposed but not opened. If you share an adapter among threads this definitely happens occasionly hence you should not share an adapter among threads.

For testing: Please override Dispose(bool) in the generated DataAccessAdapter class, as well as the method CloseConnection().

CloseConnection() will likely be called a lot, so you should use the stacktrace you posted (i.e. the part you cut off which ran through your own app) to get back to this point in your application and place a breakpoint in CloseConnection() and Dispose() to see which part disposes the adapter or calls close connection...

In our tests we can't reproduce this behavior so your code must use the adapter in a scenario we don't have in a test.

I just found the problem: we had some using statements in code, whereby the DataAccessAdapter has been disposed too early. Due to the complex code it was difficult to find these using statements. I removed these statements and now it works again.

This means that with LLBLGen Pro version 2.0 although disposing the DataAccessAdapters it could be re-used, thus the disposing didn't work correctly?

Thanks for your support.

Floeru wrote:

I just found the problem: we had some using statements in code, whereby the DataAccessAdapter has been disposed too early. Due to the complex code it was difficult to find these using statements. I removed these statements and now it works again.

This means that with LLBLGen Pro version 2.0 although disposing the DataAccessAdapters it could be re-used, thus the disposing didn't work correctly?

Thanks for your support.

It did dispose, but we didn't have a check on that in the code, so it simply continued with business as usual, while it should have thrown a dispose exception in that case, so we added a check for that in v2.6