Cashing ADO connections between application sessions

  • Thread starter Thread starter Alexander Nenashev
  • Start date Start date
A

Alexander Nenashev

i'm writing client apps that connect to
ms sql/olap servers during startup.
that takes about 10-20 seconds in our network.
so quick testing of the code's changes (especially when
making ui) isn't possible.

i've tried to cash ADO connection objects
in ActiveX exe component written in VB 6.0.

but unfortunately i couldn't use the Connection objects
with ADODB.Recordset, ADOMD.Cellset, ADOMD.Catalog
and so on. I get COM error in that case.

i guess the Connection object should be created in the same process
as consumer objects, but not sure.

so i moved all ADODB.Recordset, ADOMD.Cellset, ADOMD.Catalog
creation to ActiveX exe too.

it works but working with these objects is slowly because of marshaling.

maybe something like that could be realized with ADO.NET?

any suggestions???
 
¤ i'm writing client apps that connect to
¤ ms sql/olap servers during startup.
¤ that takes about 10-20 seconds in our network.
¤ so quick testing of the code's changes (especially when
¤ making ui) isn't possible.
¤
¤ i've tried to cash ADO connection objects
¤ in ActiveX exe component written in VB 6.0.
¤
¤ but unfortunately i couldn't use the Connection objects
¤ with ADODB.Recordset, ADOMD.Cellset, ADOMD.Catalog
¤ and so on. I get COM error in that case.
¤
¤ i guess the Connection object should be created in the same process
¤ as consumer objects, but not sure.
¤
¤ so i moved all ADODB.Recordset, ADOMD.Cellset, ADOMD.Catalog
¤ creation to ActiveX exe too.
¤
¤ it works but working with these objects is slowly because of marshaling.
¤
¤ maybe something like that could be realized with ADO.NET?

ADO Connection objects can't be marshaled across processes so that is why you were encountering the
connection problem.

With respect to your ActiveX EXE you're probably experiencing blocking problems when multiple users
request a connection simultaneously. This type of COM component doesn't natively support
multi-threading.

I don't know what tools you are using to develop your client applications but you might want to
consider porting your data access code to a web service. If your clients are COM based you can port
your code to an ActiveX DLL and run it under COM+ on your server.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Back
Top