That explanation makes perfect sense. The restriction being in the SQL Server driver and not on ODBC itself is a good distinction.
Thanks :-) Steve H. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Nick Gorham Sent: Saturday, September 29, 2001 1:29 PM To: Steve Howard Cc: Tim Harsch; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: selector screws do in ODBC 0.28 Steve Howard wrote: > Nick, > > Picky is good. It was my understanding that this was an ODBC restriction. > I've also seen the same error in the test bed in applications written in C > and Java and that was the explanation we had come to accept No its a restriction of the SQL Server ODBC driver, not ODBC itself, there is a SQLGetInfo call (SQL_MAX_CONCURRENT_ACTIVITIES) that allows the application to check on this. I have to use this in both our SQLEngine and Kylix dbExpress driver to alter the operation, and create additional connections as required. > I'm not arguing with you, but if the restriction is with SQL Server, then my > understanding of something else needs to change. I might have a nebulous > grasp on how this can be, but I would like to hear from someone else to > (match|firm) up what I'm thinking. Well the restriction is with TDS the network protocol that SQL Server (And Sybase) uses. put simply in non dynamic mode one a query is executed dat just comes back, and keed comming untill the end, so there is no way (other that a cancel) to do anything else on that connection until all the results have come back. The ODBC driver checks this for forward only stmts, but for dynamic it doesn't. With these the data comes back a row at a time, so you can in theory muliplex statements. However the problem is that unless all the data is returned the protocol stream gets confused, hence the spin wait. > The following ISQL script does the same sort of thing (it's bad practice to > grant permissions to individual users, but it works as an example), but will > not return an error, even though the grant is being executed while the usr > cursor is still active in the established connection. Looking at the current > activity while it takes place, it looks as if it handles it as a whole and > not as individual statements (That's my current theory on how it's possible > in an ISQL script), but profiler still shows a statement being prepared, > executed, and individual fetches being done, and the grant statement being > executed while usr is still active, and I don't see any additional > connections being made - only the existing connection is referred to. Do you > have a moment to take on explaining this? Well I would guess its because the script is operating on the server where the protocol restrictions dont apply, so there will be no such problem. Of course I could be wrong, this is all just summise. MS could give you a exact answer, but I doub't they would :-) -- Nick Gorham Emacs would be a great operating system if it just had a decent text editor...
