New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State still in SentClientRequest when 'done' event was fired #9
Comments
Hello, I have a similar problem. |
Sorry for the lack of activity on this issue. I intend to take a proper look at it this weekend. |
Because a request can execute multiple statements, multiple
So the request's
There was also a bug in the Connection's state machine which prevented a new request from being initiated in the Request's completion callback. I've fixed that bug, and added a test to test/integration/connection-test.coffee to verify that a new Request can be initiated. |
Thanks! Does the current code provide output parameter support? And, should multiple result sets be obtained through the new Request("select ...",
function processResult1(){},
function processResult2(){},
function completion(){}
); Great job! |
No, I am afraid that it does not. I am looking to add support for parameterised requests next, and this will include input and output parameters.
No, multiple result sets are provided for with the existing API. Each result set will result in 0 or more
In most use cases I imagine that it would be best to stick to requests with statements that cause only a single result set. |
Enabling multiple result sets indeed satisfies some real needs which should not be ignored totally in my humble opinion :P Great plan on supporting parameterised request! |
Multiple result set are supported, as I mentioned previously. Are you suggesting that multiple results should be buffered and presented to (multiple) request completion callbacks? What would be the advantage over the current events that provide the result sets? What would happen if the number of callbacks doesn't match the number of result sets? Result set rows can't be buffered, as that might result in vast amounts of memory being consumed. In general I'd prefer to keep the API relatively low level, and fairly close to the TDS protocol. A higher level API could always be built on top. I'm sorry if I'm misunderstanding what you're asking for. |
I'm sorry for making you feel confused. I'm arguing for
since in some real scenarios, multi result sets helps. The current implementation in supporting multiple result sets is so great that I have no idea how it could be improved :) I'm also fond of the philosophy -- a TDS spec's counterpoint in JavaScript / coffee script. I'll keep playing tedious :P |
Thanks. I'm pleased that we're in broad agreement. |
HI Pekim, I am doing a simple insert in nodejs using tedious and when I am trying to put this in a transactions I am getting the error - "Invalid state; requests can only be made in the LoggedIn state, not the SentClientRequest state" My Code: var storedProcName = '[Employess].[dbo].[sp_InsertEmployee]';
and the stored proc is a simple insert which return the @@IDENTITY when completed. Can you please help ? Thanks |
Hi pekim, One more question.. How do I call the request in a foreach loop as I need to insert multiple records./ SImple example.. Insert multiple locations for a customer ? How would I do that? Where do I call the foreach loop ?? In the callback of request?? How?? Thanks in advance. Regards, |
So, I am having the same issue as @kimi23 - was a solution to this ever found? Are there docs somewhere that detail exactly how the tedious transaction logic should work? |
When I try to benchmark a simple query as below:
below exception was thrown:
Invalid state; requests can only be made in the LoggedIn state, not the SentClientRequest state
The text was updated successfully, but these errors were encountered: