problem with different methods of invoking stored procedures through ADO



Hi all

I may have missed something obvious, but the two methods of assigining
parameters when calling an SQL stored procedure produce different
results for a routine.

In the example below, the commented out lines
eg

' ,parameters.append .......

resulted in the stored procedure failing to execute an Update sql
statement in a MS SQL stored procedure, but by changing to

..parameters("@.....

the routine worked fine.

Can anyone suggest a reason for the differing performance ? The
parameter @CLAIM_ID is the crux of the problem, as when I hard code
the value ( 6469) in the WHERE clause, the UPDATE statement works
fine for the other values.

Many Thanks in advance

RW

========================================================
Code examples

VB

With connCmd

.ActiveConnection = GconCCG
.CommandType = adCmdStoredProc
.CommandText = "usp_Fixed_Allocation_DeAllocateClaim"

' Procedure fails to find the record if i use these lines
'.Parameters.Append .CreateParameter("@CLAIM_ID", adInteger,
adParamInput, lngCLAIM_ID)
'.Parameters.Append .CreateParameter("@NewComments", adVarChar,
adParamInput, 255, trim(strComments))
'.Parameters.Append .CreateParameter("@AllocReason", adInteger,
adParamInput, lngReallocationReason)

' these work fine
.Parameters("@CLAIM_ID") = lngCLAIM_ID
.Parameters("@NewComments") = Trim(strComments)
.Parameters("@AllocReason") = lngReallocationReason



.Execute RecordsAffected:=LngRecsAffected

End With


USP contains :
..........................

UPDATE dbo.CLAIM_QUEUE_ALLOCATION
SET
dbo.CLAIM_QUEUE_ALLOCATION.[CURRENT] = 'N',
REALLOCATION_REASON = @AllocReason,
COMMENTS = @NewComments,
REALLOCATION_DATE =@currentdate
WHERE (
CLAIM_ID =@Claim_Id -- 6469
and dbo.CLAIM_QUEUE_ALLOCATION.[CURRENT] = 'Y'
)


.



Relevant Pages

  • Re: converting/casting before submitting
    ... Also, FIY, TinyInt is a value from 0-255, which in .Net maps to a Byte and ... So I next just went ahead> and tried to submit the value as is to the stored procedure to see if there> would be a problem. ... The SQL stored procedure was expecting a TinyInt as> declared in the stored procedure. ... have I been wasting time> and/or slowing performance converting/casting myself all this time? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: converting/casting before submitting
    ... Also, FIY, TinyInt is a value from 0-255, which in .Net maps to a Byte and ... So I next just went ahead> and tried to submit the value as is to the stored procedure to see if there> would be a problem. ... The SQL stored procedure was expecting a TinyInt as> declared in the stored procedure. ... have I been wasting time> and/or slowing performance converting/casting myself all this time? ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Capturing SQL Stored Procedure Return Codes
    ... For a Recordset-returning Command: ... Returns a Recordset object reference or Nothing. ... My point is that I can force the SQL stored procedure to return a negative ... How do I capture return codes from a SQL Stored Procedure? ...
    (microsoft.public.access.modulesdaovba)
  • converting/casting before submitting
    ... I have typically always used one of the VB CType functions (not CType itself ... before passing it as a parameter to a SQL stored procedure. ... field of type TinyInt which is an 8bit integer. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Stored procedure Output Parameter headache
    ... I have the following code chunk for a page which accesses an SQL Server 2000 stored procedure that takes an SSN and a Last Name and checks our database for a match. ... Dim cmdDWExport ... .Parameters.Append .CreateParameter("@LastName", adVarChar, adParamInput, 25, txtLName) ... declare @RetMsg varchar ...
    (microsoft.public.inetserver.asp.db)