This is a multi-part message in MIME format.
------=_NextPart_000_0048_01C0321D.AA1FE030
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi all
Certainly the trickiest problem we've found yet...
We are running some stored procs on our site, fairly complex and slightly
time intensive. These incorporate parameters, temporary tables, update,
deletes, inserts, selects and sometimes cursors. ie. basic proc stuff.
The procs work fine when run by a single user, however we have noticed that
when hit by concurrent sessions they go wierd. In these instances the procs
seem to "terminate". They return no result set, but even more than that,
they cease at different apparently random points within through the proc. If
the page is refreshed, no problem. When we have mutliple users just hitting
SQLServer (not running the proc through CF), no problem. When we run normal
queries as opposed to procs through CF, no problem. But for some reason
multiple hits on a proc from CF gives this problem. Could it be threading
via ODBC that's causing the problem? It doesn't even give an error, but
rather says there are no rows in the result set, which is patently not true.
We've proven that even when this happens, the proc is getting run, and the
parameters are being processed properly, so the best we can come up with is
that a thread in the stored proc is getting terminated when another thread
hits it. All CF sessions are locked (both write and read) and we have
discovered that sessions are not being lost and are being handled correctly.
Seems impossible to me, but I'm no expert on the back end stuff.
I know you guys like to see code, but there doesn't seem to be much point.
The code works just fine, and it's long and won't tell you anything that I
haven't already. I'm just interested to know if anyone has heard of such a
thing? Why would a proc be run but not get to the end, but equally not
trigger an error? And how can we fix it? We are stumped with a capital 'st'
TIA
Garry
------=_NextPart_000_0048_01C0321D.AA1FE030
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D799310408-09102000>Hi=20
all</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D799310408-09102000>Certainly the=20
trickiest problem we've found yet...</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D799310408-09102000></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D799310408-09102000>We are running =
some stored=20
procs on our site, fairly complex and slightly time intensive. These =
incorporate=20
parameters, temporary tables, update, deletes, inserts, selects and =
sometimes=20
cursors. ie. basic proc stuff.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D799310408-09102000>The =
procs work fine=20
when run by a single user, however we have noticed that when hit by =
concurrent=20
sessions they go wierd. In these instances the procs seem to =
"terminate".=20
They return no result set, but even more than that, they cease at =
different=20
apparently random points within through the proc. If the page is =
refreshed,=20
no problem. When we have mutliple users just hitting SQLServer (not =
running the=20
proc through CF), no problem. When we run normal queries as opposed to =
procs=20
through CF, no problem. But for some reason multiple hits on a proc from =
CF=20
gives this problem. Could it be threading via ODBC that's causing the =
problem?=20
It doesn't even give an error, but rather says there are no rows in the =
result=20
set, which is patently not true. We've proven that even when this =
happens, the=20
proc is getting run, and the parameters are being processed properly, so =
the=20
best we can come up with is that a thread in the stored proc is getting=20
terminated when another thread hits it. All CF sessions are locked (both =
write=20
and read) and we have discovered that sessions are not being lost and =
are being=20
handled correctly. Seems impossible to me, but I'm no expert on the back =
end=20
stuff.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D799310408-09102000>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D799310408-09102000>I know =
you guys like=20
to see code, but there doesn't seem to be much point. The code works =
just fine,=20
and it's long and won't tell you anything that I haven't already. I'm =
just=20
interested to know if </SPAN></FONT></SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D799310408-09102000>anyone has heard of such a thing? Why would a =
proc be=20
run but not get to the end, but equally not trigger an error? And how =
can we fix=20
it? We are stumped with a capital 'st'</SPAN></FONT></DIV></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000>TIA</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D799310408-09102000>Garry</SPAN></FONT></DIV></BODY></HTML>
------=_NextPart_000_0048_01C0321D.AA1FE030--
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
