I'm getting a "type mismatch" problem when passing a connection object created in ASP to a Vb component
that looks like this:
public sub doStuff(sParam as string, byRef oConn as adodb.connection)
oconn.execute "mystoredproc blah blah"
...

the asp looks like this:
set conn=createObject ("adodb.connection")
set myDll=createObject ("mydll.myclass")
myDll.dostuff("helloWorld",conn)

I tested this component in VB and it worked fine. BUT when i began to pass
a connection object to it from ASP, i'd get an error:

Microsoft VBScript runtime (0x800A000D)
Type mismatch: 'clsMyClass'

After further research i found out there is only one data type in ASP
vbscript and that is the VARIANT data type. with this in mind, it occurred
to me that my parameter declaration of "byRef oConn as adodb.connection"
was the one causing the problem!

i looked at the p2p.wrox.com archives and i came upon a solution of just
declaring the param as "byref oconn", omitting the "as adodb.connection"
part. this solution worked fine but i am bothered because it doesnt seem
like good programming practice to omit the type of the variable declared
in the parameter. Is there no other way to do it? I'm thinking of a way to
somehow "typecast" the connection object coming from ASP. What are your
thoughts on this?

I suggest that it's better to pass a connection string (or DSN) to the
component and use that to create and destroy the connection object within
the component. This avoids keeping your connection object in memory for the
whole time it takes to create, use and leave your component whether it needs
it or not, which is a less scalable solution than passing in a string and
doing all that within the component itself.

2-cents,

tom mallard
seattle

-----Original Message-----
From: paolo rhais gamboa [mailto:yellowoboe@y...]
Sent: Thursday, November 21, 2002 12:16 PM
To: ASP Web HowTo
Subject: [asp_web_howto] typecasting ASP variant variables


I'm getting a "type mismatch" problem when passing a connection object
created in ASP to a Vb component that looks like this:
public sub doStuff(sParam as string, byRef oConn as adodb.connection)
oconn.execute "mystoredproc blah blah"
...

the asp looks like this:
set conn=createObject ("adodb.connection")
set myDll=createObject ("mydll.myclass")
myDll.dostuff("helloWorld",conn)

I tested this component in VB and it worked fine. BUT when i began to pass
a connection object to it from ASP, i'd get an error:

Microsoft VBScript runtime (0x800A000D)
Type mismatch: 'clsMyClass'

After further research i found out there is only one data type in ASP
vbscript and that is the VARIANT data type. with this in mind, it occurred
to me that my parameter declaration of "byRef oConn as adodb.connection"
was the one causing the problem!

i looked at the p2p.wrox.com archives and i came upon a solution of just
declaring the param as "byref oconn", omitting the "as adodb.connection"
part. this solution worked fine but i am bothered because it doesnt seem
like good programming practice to omit the type of the variable declared
in the parameter. Is there no other way to do it? I'm thinking of a way to
somehow "typecast" the connection object coming from ASP. What are your
thoughts on this?

hello tom!
I was thinking of passing the connection object so i can implement 
conn.begintrans and conn.endtrans. if i create/destroy the object from 
within VB, how then do you suggest i implement transactions?

Thanks for your reply!

.
paolog

> I suggest that it's better to pass a connection string (or DSN) to the
component and use that to create and destroy the connection object within
the component. This avoids keeping your connection object in memory for the
whole time it takes to create, use and leave your component whether it 
needs
it or not, which is a less scalable solution than passing in a string and
doing all that within the component itself.

2-cents,

tom mallard
seattle

Paolog,

Without knowing more about it, my reaction is to include the trans as a sub
or function within the component. That kinda' forces putting the error
handling for your trans within the component as well. This should be OK
because most of the time no error will occur and you can return a boolean
parameter to know to process the error from the asp page and restart the asp
work flow if it happens.

If you already have the error handling in vbscript for an asp page or
function, create a windows host component out of it. Makes it easy to call
from the vb then. There's a wizard for this that downloads with the
scripting doc's from MS.

tom

-----Original Message-----
From: paolo rhais gamboa [mailto:yellowoboe@y...]
Sent: Sunday, November 24, 2002 12:17 AM
To: ASP Web HowTo
Subject: [asp_web_howto] RE: typecasting ASP variant variables


hello tom!
I was thinking of passing the connection object so i can implement
conn.begintrans and conn.endtrans. if i create/destroy the object from
within VB, how then do you suggest i implement transactions?

Thanks for your reply!

.
paolog

> I suggest that it's better to pass a connection string (or DSN) to the
component and use that to create and destroy the connection object within
the component. This avoids keeping your connection object in memory for the
whole time it takes to create, use and leave your component whether it
needs
it or not, which is a less scalable solution than passing in a string and
doing all that within the component itself.

2-cents,

tom mallard
seattle

hello tom! 

Again, thank you for your replies. Ideally, i would have liked to have the transactions as a sub within the component but i couldn't
figure out how to do it. 

You see i have a long form with a lot of information in it. i have divided this form to span four pages. my current design is to
post the information from each page into a "hidden" page and once i reach the last page, i will then submit the "hidden" page.

in the hidden page, i have a COM method for each particular transaction something like this:
userid = myDll.addUser(name)
myDll.addAddress(userId, address)
myDll.addContactInfo(userID,contactInfo)

now i need the transaction support to span all the methods from addUser to contactInfo. If i include the transaction support code
INSIDE the dlls, it wouldn't be of much use to me because then the transaction would be defined per method and not spanning the
collection of methods... (i hope that didn't confuse you..!)

and so now it looks like this:

'return a connection object
set conn=myDll.createConnection

conn.begintrans
userid = myDll.addUser(conn, name)
myDll.addAddress(conn, userId, address)
myDll.addContactInfo(conn, userID,contactInfo)
conn.endTrans

as i was doing the above code, i found myself in front of a "type mismatch" error for every method. the cause was i declared the
parameters as:

addAddress(conn as Adodb.connection, etc...)

its the "as adodb.connection" that was giving me a problem because ASP passes the connection object as a variant data type! it seems
that typecasting isn't automatic for pass by ref variables.

.
paolog

> Paolog,

Without knowing more about it, my reaction is to include the trans as a sub
or function within the component. That kinda' forces putting the error
handling for your trans within the component as well. This should be OK
because most of the time no error will occur and you can return a boolean
parameter to know to process the error from the asp page and restart the asp
work flow if it happens.

If you already have the error handling in vbscript for an asp page or
function, create a windows host component out of it. Makes it easy to call
from the vb then. There's a wizard for this that downloads with the
scripting doc's from MS.

tom

Hmmm, that's a reason not to pass objects, but there are others as well.
However, why do you call the dll for every page? Consider just passing the
data and waiting until the last page to process the information. This way
you can define your pages as a single multi-part form and the final submit
is the only asp page to use the dll.

Even if you use the pages as individual forms, what it means is that if the
user hits the back button they can change values without affecting anything,
processing will be faster by not having to perform db operations for every
hit by every user. And, if the user leaves before finishing the process
nothing is affected.

Instead, just pass hidden fields with the values from page to page until the
final page which submits the whole mess for processing. The form pages
usually contain javascript to detect errors and have the user fix them
before going to the next. The final page will create your dll and pass in
all the data fields at one time.

The only type of error you should get is one from the db server being
unavailable since all the data has been checked (I check/typecast the data
again on the asp page, redundant but required for most enterprise level
software). The transaction should be part of the db procedure, since you're
not using ADO anyway it doesn't make sense to use ADO transactions then go
to a dll which does the insert/change/delete at the data source probably
using a stored proc.

Whatever sql is used should contain the BEGIN TRANS - END TRANS directive,
not ADO. Rollbacks should be handled from the db while processing the one
trans, much easier than having it blow in ADO then you must rollback from
the asp page. The connection is only needed for this final process so can be
created and destroyed from the dll.

Cold & sunny in Seattle,

tom

-----Original Message-----
From: paolo rhais gamboa [mailto:yellowoboe@y...]
Sent: Wednesday, November 27, 2002 1:32 AM
To: ASP Web HowTo
Subject: [asp_web_howto] RE: typecasting ASP variant variables


hello tom!

Again, thank you for your replies. Ideally, i would have liked to have the
transactions as a sub within the component but i couldn't figure out how to
do it.

You see i have a long form with a lot of information in it. i have divided
this form to span four pages. my current design is to post the information
from each page into a "hidden" page and once i reach the last page, i will
then submit the "hidden" page.

in the hidden page, i have a COM method for each particular transaction
something like this:
userid = myDll.addUser(name)
myDll.addAddress(userId, address)
myDll.addContactInfo(userID,contactInfo)

now i need the transaction support to span all the methods from addUser to
contactInfo. If i include the transaction support code INSIDE the dlls, it
wouldn't be of much use to me because then the transaction would be defined
per method and not spanning the collection of methods... (i hope that didn't
confuse you..!)

and so now it looks like this:

'return a connection object
set conn=myDll.createConnection

conn.begintrans
userid = myDll.addUser(conn, name)
myDll.addAddress(conn, userId, address)
myDll.addContactInfo(conn, userID,contactInfo)
conn.endTrans

as i was doing the above code, i found myself in front of a "type mismatch"
error for every method. the cause was i declared the parameters as:

addAddress(conn as Adodb.connection, etc...)

its the "as adodb.connection" that was giving me a problem because ASP
passes the connection object as a variant data type! it seems that
typecasting isn't automatic for pass by ref variables.

.
paolog

> Paolog,

Without knowing more about it, my reaction is to include the trans as a sub
or function within the component. That kinda' forces putting the error
handling for your trans within the component as well. This should be OK
because most of the time no error will occur and you can return a boolean
parameter to know to process the error from the asp page and restart the asp
work flow if it happens.

If you already have the error handling in vbscript for an asp page or
function, create a windows host component out of it. Makes it easy to call
from the vb then. There's a wizard for this that downloads with the
scripting doc's from MS.

tom