> <CFstoredproc
> Procedure=3D"GetMailingLabList_MyEnrolmentList" datasource=3D#dsn#
> ReturnCode=3D"YES">
> <cfprocparam type=3D"In"
> cfsqltype=3D"CF_SQL_INTEGER" variable=3D"@MYUSERID" value="#CLIENT.User_I=
> d#"
> null="No">
> <CFPROCRESULT NAME =3D MyEnrolmentList>
> </CfStoredProc>
Nothing wrong with this. Although I would prefer a test for the
#Client.User_Id# before you pass it to the stored proc.
<cfif isdefined("Client.User_Id") and isnumeric(Client.User_Id)>
... call sp
</cfif>
There is really no need then to specify the null="no" as it will only pass
a valid numeric value. At the moment what if the client.user_id field was
empty and you passed it to the sp like that?
> > > After the upgrade to MX, I'm encountering problems with=20
> > executing some=20
> > > stored procedures. The stored procs grabs data and places it into a=20
> > > temporary table which is then read by a DTS package to=20
> > produce a csv=20
> > > file. Now the problem I am having is that SQL is placing=20
> > locks on the=20
> > > temporary table which is causing the system to just hang. Of course=20
> > > everything works fine on an exact duplicate of the system=20
> > on my machine.
> > > Any ideas would be _greatly_ appriciated.
Can we see the code in the stored proc that creates the temp table? This
looks to me like a db locking issue. How is the dts called? From within
the sp? Or from another db call?
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004
