Hi Tim,

any news on this yet?

Chris Holland

Chris,

<< any news on this yet? >>

Not yet.  I'm finishing up the EDB ODBC Driver, and I'm going to test it
with it also to see if I can replicate it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

<< any news on this yet? >>

Okay, I ran some tests this morning, and it appears as though there is a
Dispose (or lack of Dispose) issue with the ODBC.NET data provider.  When I
run the tests, the number of internal statement objects on the same
connection accumulates up to 40+, and then starts to de-accumulate after a
certain point.   This tells me that the statement handles are being freed up
in the finalizer being called by the GC, and that is definitely a no-no
since the GC is most likely doing this in a thread.  That, of course, means
that there is re-entrant access to the same connection occurring across
multiple threads, and DBISAM (and EDB) definitely don't like that at all
since it violates the one-connection-per-thread rule.

What to do from here, however, is a different story.  I'll have to see what
I can find out further.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

I've posted a log of the activity in the Binaries newsgroup.  You can see
what is going on by seeing all of the statement handles being allocated, and
then large runs of them getting freed later on.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

If I add a Dispose() at the end of each loop then the AV does not occur.
I just did not think I would need it.
I guess using C# has just made me lazy as I expect it to tidy up after
me

Chris Holland

Tim Young [Elevate Software] wrote:
> Chris,
>
> << any news on this yet? >>
>
> Okay, I ran some tests this morning, and it appears as though there is a
> Dispose (or lack of Dispose) issue with the ODBC.NET data provider.  When I
> run the tests, the number of internal statement objects on the same
> connection accumulates up to 40+, and then starts to de-accumulate after a
> certain point.   This tells me that the statement handles are being freed up
> in the finalizer being called by the GC, and that is definitely a no-no
> since the GC is most likely doing this in a thread.  That, of course, means
> that there is re-entrant access to the same connection occurring across
> multiple threads, and DBISAM (and EDB) definitely don't like that at all
> since it violates the one-connection-per-thread rule.
>
> What to do from here, however, is a different story.  I'll have to see what
> I can find out further.
>

Chris,

<< If I add a Dispose() at the end of each loop then the AV does not occur.
I just did not think I would need it.
I guess using C# has just made me lazy as I expect it to tidy up after me
>>

Yes, I finally put 2 and 2 together and realized that the solution was
simply for you to call Dispose. Here's a blog article that discusses
this also:

http://davidhayden.com/blog/dave/archive/2005/01/13/773.aspx

The same would hold true for your connection issue.

--
Tim Young
Elevate Software
www.elevatesoft.com