Problem passing ADO command objects as parameters in MTS 
Author Message
 Problem passing ADO command objects as parameters in MTS

Brief description of problem:
Win NT 4.0, VB6, latest service packs. ADO 2.5

I've declared an ADO command object in one method of a class in an MTS
package. The command object is used to call a SQL Server stored procedure.
It has several parameters (added using .Type, .Direction .Size, .Append as
normal)
Once I've set all the parameters, I pass this command object to a procedure
in a different MTS package.
eg:

In calling class:
Dim cmdTest as ADODB.command
Dim Ret as Boolean

set cmdTest = new ADODB.command
<set parameters>

Ret = myclass.execSP(cmdTest)
etc

and in myclass:
Public Function execSP (mySP as ADODB.command) as Boolean

<Get DB Connection>

<Perform logging etc>

<Execute stored proc>

End Function

However, as soon as I set the ActiveConnection property of the Command
object in the execSP function, I get:

Runtime error '3001':
The application is using arguments that are of the wrong type, are out of
acceptable range, or are in conflict with one another.

I know this is not actually the case, because when I run *exactly* the same
code outside MTS, it works fine. Also, when I move execSP to be private to
the calling class, it also works fine.

It seems like there is a problem with MTS and passing the ADO command object
reference.
I have tried passing the reference ByVal and ByRef, neither work.
I've tried moving the DLL that contains myclass to the same package that the
calling function inhabits, but it still doesn't work (I did this as I
thought it might have something to do with activity boundaries?)
Incidently, I'm creating myclass using the recommended "GetObjectContext()"
syntax.

Has anybody had similar problems?
Or has anybody got any suggestions?

Thanks in advance for any help.

Stu



Sat, 27 Dec 2003 03:46:22 GMT  
 Problem passing ADO command objects as parameters in MTS
Stu,
Keep your "data access" in one class.  Don't marshal the Command to another package (in another
process).

I always use a data class, business class, and presentation class when creating DNA applications.

--

Thanks,
Carl Prothman
Microsoft Visual Basic MVP
http://www.able-consulting.com


Quote:
> Brief description of problem:
> Win NT 4.0, VB6, latest service packs. ADO 2.5

> I've declared an ADO command object in one method of a class in an MTS
> package. The command object is used to call a SQL Server stored procedure.
> It has several parameters (added using .Type, .Direction .Size, .Append as
> normal)
> Once I've set all the parameters, I pass this command object to a procedure
> in a different MTS package.
> eg:

> In calling class:
> Dim cmdTest as ADODB.command
> Dim Ret as Boolean

> set cmdTest = new ADODB.command
> <set parameters>

> Ret = myclass.execSP(cmdTest)
> etc

> and in myclass:
> Public Function execSP (mySP as ADODB.command) as Boolean

> <Get DB Connection>

> <Perform logging etc>

> <Execute stored proc>

> End Function

> However, as soon as I set the ActiveConnection property of the Command
> object in the execSP function, I get:

> Runtime error '3001':
> The application is using arguments that are of the wrong type, are out of
> acceptable range, or are in conflict with one another.

> I know this is not actually the case, because when I run *exactly* the same
> code outside MTS, it works fine. Also, when I move execSP to be private to
> the calling class, it also works fine.

> It seems like there is a problem with MTS and passing the ADO command object
> reference.
> I have tried passing the reference ByVal and ByRef, neither work.
> I've tried moving the DLL that contains myclass to the same package that the
> calling function inhabits, but it still doesn't work (I did this as I
> thought it might have something to do with activity boundaries?)
> Incidently, I'm creating myclass using the recommended "GetObjectContext()"
> syntax.

> Has anybody had similar problems?
> Or has anybody got any suggestions?

> Thanks in advance for any help.

> Stu



Sun, 28 Dec 2003 01:25:36 GMT  
 Problem passing ADO command objects as parameters in MTS
Carl,

Thanks for replying. However, while this will work - I have one objection to
this solution:
If you really mean keep all the data access code in one *class*, then surely
this class is going to contain hundreds of procedures, which goes against
all examples I have seen that "componentize" applications.
Also, surely this would inhibit scalability, since all the "work" would be
being perfomed in one place...
And what about transactions? If I need to perform several DB operations that
need to be in one transaction, this approach doesn't seem to facilitate
that?

Perhaps I'm just missing something...  :)

Stu


Quote:
> Stu,
> Keep your "data access" in one class.  Don't marshal the Command to

another package (in another
Quote:
> process).

> I always use a data class, business class, and presentation class when

creating DNA applications.
Quote:

> --

> Thanks,
> Carl Prothman
> Microsoft Visual Basic MVP
> http://www.able-consulting.com



> > Brief description of problem:
> > Win NT 4.0, VB6, latest service packs. ADO 2.5

> > I've declared an ADO command object in one method of a class in an MTS
> > package. The command object is used to call a SQL Server stored
procedure.
> > It has several parameters (added using .Type, .Direction .Size, .Append
as
> > normal)
> > Once I've set all the parameters, I pass this command object to a
procedure
> > in a different MTS package.
> > eg:

> > In calling class:
> > Dim cmdTest as ADODB.command
> > Dim Ret as Boolean

> > set cmdTest = new ADODB.command
> > <set parameters>

> > Ret = myclass.execSP(cmdTest)
> > etc

> > and in myclass:
> > Public Function execSP (mySP as ADODB.command) as Boolean

> > <Get DB Connection>

> > <Perform logging etc>

> > <Execute stored proc>

> > End Function

> > However, as soon as I set the ActiveConnection property of the Command
> > object in the execSP function, I get:

> > Runtime error '3001':
> > The application is using arguments that are of the wrong type, are out
of
> > acceptable range, or are in conflict with one another.

> > I know this is not actually the case, because when I run *exactly* the
same
> > code outside MTS, it works fine. Also, when I move execSP to be private
to
> > the calling class, it also works fine.

> > It seems like there is a problem with MTS and passing the ADO command
object
> > reference.
> > I have tried passing the reference ByVal and ByRef, neither work.
> > I've tried moving the DLL that contains myclass to the same package that
the
> > calling function inhabits, but it still doesn't work (I did this as I
> > thought it might have something to do with activity boundaries?)
> > Incidently, I'm creating myclass using the recommended

"GetObjectContext()"

- Show quoted text -

Quote:
> > syntax.

> > Has anybody had similar problems?
> > Or has anybody got any suggestions?

> > Thanks in advance for any help.

> > Stu



Sun, 28 Dec 2003 02:14:27 GMT  
 Problem passing ADO command objects as parameters in MTS
FalseDawn,
Sorry, one data class per table(s) depending on how you've mapped your objects to your tables.  And
each class implements the base CRUD for the table(s).

Use COM+ for transactions.  Either mark your "base" class as requires transactions,
http://msdn.microsoft.com/library/en-us/cossdk/htm/pgprimer_1enn.asp?...
or control the tranasactions by-hand via the TransactionContext object
http://msdn.microsoft.com/library/en-us/cossdk/htm/transactioncontext...

--

Thanks,
Carl Prothman
Microsoft Visual Basic MVP
http://www.able-consulting.com


Quote:
> Carl,

> Thanks for replying. However, while this will work - I have one objection to
> this solution:
> If you really mean keep all the data access code in one *class*, then surely
> this class is going to contain hundreds of procedures, which goes against
> all examples I have seen that "componentize" applications.
> Also, surely this would inhibit scalability, since all the "work" would be
> being perfomed in one place...
> And what about transactions? If I need to perform several DB operations that
> need to be in one transaction, this approach doesn't seem to facilitate
> that?

> Perhaps I'm just missing something...  :)

> Stu



> > Stu,
> > Keep your "data access" in one class.  Don't marshal the Command to
> another package (in another
> > process).

> > I always use a data class, business class, and presentation class when
> creating DNA applications.

> > --

> > Thanks,
> > Carl Prothman
> > Microsoft Visual Basic MVP
> > http://www.able-consulting.com



> > > Brief description of problem:
> > > Win NT 4.0, VB6, latest service packs. ADO 2.5

> > > I've declared an ADO command object in one method of a class in an MTS
> > > package. The command object is used to call a SQL Server stored
> procedure.
> > > It has several parameters (added using .Type, .Direction .Size, .Append
> as
> > > normal)
> > > Once I've set all the parameters, I pass this command object to a
> procedure
> > > in a different MTS package.
> > > eg:

> > > In calling class:
> > > Dim cmdTest as ADODB.command
> > > Dim Ret as Boolean

> > > set cmdTest = new ADODB.command
> > > <set parameters>

> > > Ret = myclass.execSP(cmdTest)
> > > etc

> > > and in myclass:
> > > Public Function execSP (mySP as ADODB.command) as Boolean

> > > <Get DB Connection>

> > > <Perform logging etc>

> > > <Execute stored proc>

> > > End Function

> > > However, as soon as I set the ActiveConnection property of the Command
> > > object in the execSP function, I get:

> > > Runtime error '3001':
> > > The application is using arguments that are of the wrong type, are out
> of
> > > acceptable range, or are in conflict with one another.

> > > I know this is not actually the case, because when I run *exactly* the
> same
> > > code outside MTS, it works fine. Also, when I move execSP to be private
> to
> > > the calling class, it also works fine.

> > > It seems like there is a problem with MTS and passing the ADO command
> object
> > > reference.
> > > I have tried passing the reference ByVal and ByRef, neither work.
> > > I've tried moving the DLL that contains myclass to the same package that
> the
> > > calling function inhabits, but it still doesn't work (I did this as I
> > > thought it might have something to do with activity boundaries?)
> > > Incidently, I'm creating myclass using the recommended
> "GetObjectContext()"
> > > syntax.

> > > Has anybody had similar problems?
> > > Or has anybody got any suggestions?

> > > Thanks in advance for any help.

> > > Stu



Sun, 28 Dec 2003 02:51:32 GMT  
 Problem passing ADO command objects as parameters in MTS
Carl,
This is basically what I was doing. My original reason for wanting to pass
an ADO command to another class is that this class acts as a "wrapper" of
sorts for the ADO object model. Within this class, I have a centralised area
for ADO error-trapping and can easily write code to log all SQL executed and
stored procedures called.

I don't really want this code duplicated in every "base" class...

Any ideas?

Cheers,
Stu


Quote:
> FalseDawn,
> Sorry, one data class per table(s) depending on how you've mapped your

objects to your tables.  And
Quote:
> each class implements the base CRUD for the table(s).

> Use COM+ for transactions.  Either mark your "base" class as requires
transactions,

http://msdn.microsoft.com/library/en-us/cossdk/htm/pgprimer_1enn.asp?...
rue
Quote:
> or control the tranasactions by-hand via the TransactionContext object

http://msdn.microsoft.com/library/en-us/cossdk/htm/transactioncontext...
sp?frame=true
Quote:

> --

> Thanks,
> Carl Prothman
> Microsoft Visual Basic MVP
> http://www.able-consulting.com



> > Carl,

> > Thanks for replying. However, while this will work - I have one
objection to
> > this solution:
> > If you really mean keep all the data access code in one *class*, then
surely
> > this class is going to contain hundreds of procedures, which goes
against
> > all examples I have seen that "componentize" applications.
> > Also, surely this would inhibit scalability, since all the "work" would
be
> > being perfomed in one place...
> > And what about transactions? If I need to perform several DB operations
that
> > need to be in one transaction, this approach doesn't seem to facilitate
> > that?

> > Perhaps I'm just missing something...  :)

> > Stu



> > > Stu,
> > > Keep your "data access" in one class.  Don't marshal the Command to
> > another package (in another
> > > process).

> > > I always use a data class, business class, and presentation class when
> > creating DNA applications.

> > > --

> > > Thanks,
> > > Carl Prothman
> > > Microsoft Visual Basic MVP
> > > http://www.able-consulting.com



> > > > Brief description of problem:
> > > > Win NT 4.0, VB6, latest service packs. ADO 2.5

> > > > I've declared an ADO command object in one method of a class in an
MTS
> > > > package. The command object is used to call a SQL Server stored
> > procedure.
> > > > It has several parameters (added using .Type, .Direction .Size,
.Append
> > as
> > > > normal)
> > > > Once I've set all the parameters, I pass this command object to a
> > procedure
> > > > in a different MTS package.
> > > > eg:

> > > > In calling class:
> > > > Dim cmdTest as ADODB.command
> > > > Dim Ret as Boolean

> > > > set cmdTest = new ADODB.command
> > > > <set parameters>

> > > > Ret = myclass.execSP(cmdTest)
> > > > etc

> > > > and in myclass:
> > > > Public Function execSP (mySP as ADODB.command) as Boolean

> > > > <Get DB Connection>

> > > > <Perform logging etc>

> > > > <Execute stored proc>

> > > > End Function

> > > > However, as soon as I set the ActiveConnection property of the
Command
> > > > object in the execSP function, I get:

> > > > Runtime error '3001':
> > > > The application is using arguments that are of the wrong type, are
out
> > of
> > > > acceptable range, or are in conflict with one another.

> > > > I know this is not actually the case, because when I run *exactly*
the
> > same
> > > > code outside MTS, it works fine. Also, when I move execSP to be
private
> > to
> > > > the calling class, it also works fine.

> > > > It seems like there is a problem with MTS and passing the ADO
command
> > object
> > > > reference.
> > > > I have tried passing the reference ByVal and ByRef, neither work.
> > > > I've tried moving the DLL that contains myclass to the same package
that
> > the
> > > > calling function inhabits, but it still doesn't work (I did this as
I
> > > > thought it might have something to do with activity boundaries?)
> > > > Incidently, I'm creating myclass using the recommended
> > "GetObjectContext()"
> > > > syntax.

> > > > Has anybody had similar problems?
> > > > Or has anybody got any suggestions?

> > > > Thanks in advance for any help.

> > > > Stu



Sun, 28 Dec 2003 06:19:34 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Problem passing ADO command objects as parameters in MTS

2. Problem passing parameters to DataReport/command object

3. problem: passing UDT as parameter of a method for MTS Component

4. problem: passing UDT as parameter of a method for MTS Component

5. passing a collection to a mts object with a ADO recordset

6. ADO, Oracle, MTS, using command object to open Recordset

7. 2nd Request - Passing parameters to ADO Data Environment command

8. Passing parameter to a command object

9. ] Problem passing ADO recordsets to VB6 MTS Component

10. ] Problem passing ADO recordsets to VB6 MTS Component

11. Problem sending ADODB.Command object across MTS packages !!!

12. How to create a parameter field in Command object (ADO/VB 6.0)

 

 
Powered by phpBB® Forum Software