Problem with connection withing dll in debug (XPosted and long)

[Stephanie]

I have a problem that I am trying to solve. We have a huge product with a
whole lot of ASP and VB code. VB code is all ActiveX dlls which are used by
ASP app. When I attempt to add features or fix bugs, I like to execute the
dlls in debug so I can see what is going on. (Some folks in my org seem to
have this kinda wacky bias against debugging, as if *real* programmers
should not need a debugger. Whatever, it is the fastest way for me to get
the picture.)

This product uses a technique that is different than what I have done in my
projects in the past. If I needed to make a connection to the database, I
would make it, do my work, close it within the narrowest context I could.. a
single sub / function a single class or whatever. This product instead
passes an open connection from the ASP page to a dll. Then, within the dll,
the connection is passed all over the place to various procs.

When running compiled, the dlls run fine. When running in debug mode, when
attempting to use a connection, a runtime error 3001 "Arguments are of the
wrong type, are out of acceptable range, or are in conflict with one
another." The recommended procedure up to this point when having to debug is
to change the offending code to make a new connection to use off the
connection string of the offending object. Then before checking the code in,
change it all back. What a monumental waste of time. So I want to solve this
once and for all. (Then I will be a hero and other pathetic programmers like
me who need to debug will kiss my feet. Ha Ha)

Since the code I am running is fairly complicated, I created a simple app
with one asp page and one activex dll in order to reproduce the problem. The
problem was not reproducable by me. I am clearly missing the vein here.

Thoughts I have at this point:

- The version of ADODB.Connection whcih is instantiated in the ASP page is
different than the one in VB. In VB you tell the version you wish in
References. How do I force / know what version is being instantiated in ASP?

- Different auth methods may be being used. Could this impact?

Any other thoughts on what I can pursue to investigate this? I am going to
scream if I have to keep monkeying around with things other than the work I
am trying to get done.

Thanks

Stephanie

[Paul Clement]

On Thu, 21 Apr 2005 09:45:14 -0400, "Stephanie" <Iw*********@NoWay.com> wrote:

¤ I have a problem that I am trying to solve. We have a huge product with a
¤ whole lot of ASP and VB code. VB code is all ActiveX dlls which are used by
¤ ASP app. When I attempt to add features or fix bugs, I like to execute the
¤ dlls in debug so I can see what is going on. (Some folks in my org seem to
¤ have this kinda wacky bias against debugging, as if *real* programmers
¤ should not need a debugger. Whatever, it is the fastest way for me to get
¤ the picture.)
¤
¤ This product uses a technique that is different than what I have done in my
¤ projects in the past. If I needed to make a connection to the database, I
¤ would make it, do my work, close it within the narrowest context I could.. a
¤ single sub / function a single class or whatever. This product instead
¤ passes an open connection from the ASP page to a dll. Then, within the dll,
¤ the connection is passed all over the place to various procs.
¤
¤ When running compiled, the dlls run fine. When running in debug mode, when
¤ attempting to use a connection, a runtime error 3001 "Arguments are of the
¤ wrong type, are out of acceptable range, or are in conflict with one
¤ another." The recommended procedure up to this point when having to debug is
¤ to change the offending code to make a new connection to use off the
¤ connection string of the offending object. Then before checking the code in,
¤ change it all back. What a monumental waste of time. So I want to solve this
¤ once and for all. (Then I will be a hero and other pathetic programmers like
¤ me who need to debug will kiss my feet. Ha Ha)
¤
¤ Since the code I am running is fairly complicated, I created a simple app
¤ with one asp page and one activex dll in order to reproduce the problem. The
¤ problem was not reproducable by me. I am clearly missing the vein here.
¤
¤ Thoughts I have at this point:
¤
¤ - The version of ADODB.Connection whcih is instantiated in the ASP page is
¤ different than the one in VB. In VB you tell the version you wish in
¤ References. How do I force / know what version is being instantiated in ASP?
¤
¤ - Different auth methods may be being used. Could this impact?
¤
¤ Any other thoughts on what I can pursue to investigate this? I am going to
¤ scream if I have to keep monkeying around with things other than the work I
¤ am trying to get done.

How are you actually debugging the components? Are you using VB? ASP?

You have to be very careful about passing ADO Connection objects around. Connections don't marshal
properly across process boundaries so I'm going to assume that all components in the application run
under the same process.

You also have to keep in mind that ASP only understands the Variant data type, which can cause some
headaches when using Visual Basic components. Explicitly typed arguments must be declared ByVal at
the component level in order to be compatible with ASP.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Stephanie]

"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:4b********************************@4ax.com...

On Thu, 21 Apr 2005 09:45:14 -0400, "Stephanie" <Iw*********@NoWay.com>
wrote:

¤ I have a problem that I am trying to solve. We have a huge product with
a
¤ whole lot of ASP and VB code. VB code is all ActiveX dlls which are used
by
¤ ASP app. When I attempt to add features or fix bugs, I like to execute
the
¤ dlls in debug so I can see what is going on. (Some folks in my org seem
to
¤ have this kinda wacky bias against debugging, as if *real* programmers
¤ should not need a debugger. Whatever, it is the fastest way for me to
get
¤ the picture.)
¤
¤ This product uses a technique that is different than what I have done in
my
¤ projects in the past. If I needed to make a connection to the database,
I
¤ would make it, do my work, close it within the narrowest context I
could.. a
¤ single sub / function a single class or whatever. This product instead
¤ passes an open connection from the ASP page to a dll. Then, within the
dll,
¤ the connection is passed all over the place to various procs.
¤
¤ When running compiled, the dlls run fine. When running in debug mode,
when
¤ attempting to use a connection, a runtime error 3001 "Arguments are of
the
¤ wrong type, are out of acceptable range, or are in conflict with one
¤ another." The recommended procedure up to this point when having to
debug is
¤ to change the offending code to make a new connection to use off the
¤ connection string of the offending object. Then before checking the code
in,
¤ change it all back. What a monumental waste of time. So I want to solve
this
¤ once and for all. (Then I will be a hero and other pathetic programmers
like
¤ me who need to debug will kiss my feet. Ha Ha)
¤
¤ Since the code I am running is fairly complicated, I created a simple
app
¤ with one asp page and one activex dll in order to reproduce the problem.
The
¤ problem was not reproducable by me. I am clearly missing the vein here.
¤
¤ Thoughts I have at this point:
¤
¤ - The version of ADODB.Connection whcih is instantiated in the ASP page
is
¤ different than the one in VB. In VB you tell the version you wish in
¤ References. How do I force / know what version is being instantiated in
ASP?
¤
¤ - Different auth methods may be being used. Could this impact?
¤
¤ Any other thoughts on what I can pursue to investigate this? I am going
to
¤ scream if I have to keep monkeying around with things other than the
work I
¤ am trying to get done.

How are you actually debugging the components? Are you using VB? ASP?

You have to be very careful about passing ADO Connection objects around.
Connections don't marshal
properly across process boundaries so I'm going to assume that all
components in the application run
under the same process.

You just nailed it. This is the problem. When VB is in debug the dlls are
not run under the same process. Thanks!
You also have to keep in mind that ASP only understands the Variant data
type, which can cause some
headaches when using Visual Basic components. Explicitly typed arguments
must be declared ByVal at
the component level in order to be compatible with ASP.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Mark Schupp]

"Stephanie" <Iw*********@NoWay.com> wrote in message
news:OK**************@TK2MSFTNGP14.phx.gbl...

"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:4b********************************@4ax.com...

On Thu, 21 Apr 2005 09:45:14 -0400, "Stephanie" <Iw*********@NoWay.com>
wrote:

¤ I have a problem that I am trying to solve. We have a huge product with a
¤ whole lot of ASP and VB code. VB code is all ActiveX dlls which are used by
¤ ASP app. When I attempt to add features or fix bugs, I like to execute
the
¤ dlls in debug so I can see what is going on. (Some folks in my org seem to
¤ have this kinda wacky bias against debugging, as if *real* programmers
¤ should not need a debugger. Whatever, it is the fastest way for me to
get
¤ the picture.)
¤
¤ This product uses a technique that is different than what I have done in my
¤ projects in the past. If I needed to make a connection to the database, I
¤ would make it, do my work, close it within the narrowest context I
could.. a
¤ single sub / function a single class or whatever. This product instead
¤ passes an open connection from the ASP page to a dll. Then, within the
dll,
¤ the connection is passed all over the place to various procs.
¤
¤ When running compiled, the dlls run fine. When running in debug mode,
when
¤ attempting to use a connection, a runtime error 3001 "Arguments are of
the
¤ wrong type, are out of acceptable range, or are in conflict with one
¤ another." The recommended procedure up to this point when having to
debug is
¤ to change the offending code to make a new connection to use off the
¤ connection string of the offending object. Then before checking the code in,
¤ change it all back. What a monumental waste of time. So I want to solve this
¤ once and for all. (Then I will be a hero and other pathetic programmers like
¤ me who need to debug will kiss my feet. Ha Ha)
¤
¤ Since the code I am running is fairly complicated, I created a simple
app
¤ with one asp page and one activex dll in order to reproduce the problem. The
¤ problem was not reproducable by me. I am clearly missing the vein here. ¤
¤ Thoughts I have at this point:
¤
¤ - The version of ADODB.Connection whcih is instantiated in the ASP page is
¤ different than the one in VB. In VB you tell the version you wish in
¤ References. How do I force / know what version is being instantiated in ASP?
¤
¤ - Different auth methods may be being used. Could this impact?
¤
¤ Any other thoughts on what I can pursue to investigate this? I am going to
¤ scream if I have to keep monkeying around with things other than the
work I
¤ am trying to get done.

How are you actually debugging the components? Are you using VB? ASP?

You have to be very careful about passing ADO Connection objects around.
Connections don't marshal
properly across process boundaries so I'm going to assume that all
components in the application run
under the same process.

You just nailed it. This is the problem. When VB is in debug the dlls are
not run under the same process. Thanks!

If you have a windows debugger installed on the web-server ( I use the VC++
debugger ) you can debug the IIS process containing the application. We do
this all the time and, like your app, the dbconnection is typically passed
in from the ASP page so that it does not have to be created and opened
repeatedly on the same page.

1. reset iis
2. launch task manager and identify the instances of DLLHOST.
3. launch your ASP app. This should create a new instance of DLLHOST
4. right-click on the new instance of DLLHOST and select "debug"
5. when the debugger opens you can open the desired source file. You may
have to hit a page that uses your object before you are able to set a
breakpoint.

There are a few drawbacks to this method. The principal one is that the VC
debugger doesn't understand variant arrays well so you may have to add some
debugging variables inside of loops. Also, (this one is weird), parameters
passed in ByRef do not appear to change in the debugger. The values do
actually change but the debugger shows the original value (again
necessitating some additional local variables for debugging).

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com