encapsulating dataadapter in another dll

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

i have a vb.net app that has been running successfully for two years, version
2003 for almost a year.

recently, i replaced all references to oledb.oledbdataadapter with
mydll.dataadapter. since i cant inherit from oledbdataadapter, i
encapsulated it (there is a private oledbdataadapter as a member in the
class) and exposed a few methods which i just pass through to the private
oledbdataadapter. the new oledbdataadapter is constructed inside the new()
member of mydll.dataadapter. i also construct an oledbcommandbuilder. an
oledbcommand is passed into my constructor.

the reason i do this is to log calls to .update, and how long each took. (i
am using JET and i need to do some measuring in order to improve performance.)

good news is it works most of the time. like 99%+
bad news is, of course, the other 1%

sometimes, it crashes deep in dbdataadapter with a null object reference.
when i catch the exception and do a oledbtransaction.rollback, i get another
exception that says the transaction is not idle, it is executing.

to me, it seems almost like the hidden oledbdataadapter is running
asynchronously, or maybe it is loosing context somehow. I am almost certain
that the only material difference between doing it this new way, and doing it
the old way (using oledb direclty) is that the oledbcommand is created in my
exe and the oledbdataadapter and oledbcommandbuilder are created in the dll.
that is, two different assemblies. both assemblies are built in the same
solution, both import the oledb name space.

I hope i haven't misused too many buzzwords.

so, what do y'all think, is there a problem using oledb objects together
that were constructed by two different assemblies in the same solution?
 
so, what do y'all think, is there a problem using oledb objects together
that were constructed by two different assemblies in the same solution?

Maybe you should take a look at Microsoft's Application DAta Building
Blocks. You might be able to modify their current SQL Client version for
your needs.

The app blocks are based on Microsoft's best practices... so I assume they
should work well and have been throughly tested.
 
Back
Top