I've received requests for pytsql to support the @@ROWCOUNT variable, so that print statements of the number of affected rows can be used. An example usage would be:
<select/update statement>
PRINT (@@ROWCOUNT)
The reason this doesn't work at the moment seems to be that if we don't send both statements in a single "batch" towards the SQL server, the variable gets reset. The current implementation of pytsql separates all top-level statements and sends them separately.
My suggestion would be to introduce an option along the lines of "isolate-top-level-statements" which is true by default and when enabled would retain the current behavior of the tool. However, when disabled, the batching would be done in whole groups inbetween GO commands. In this way users who want to use such "context-sensitive" commands can use the latter mode. The only downside of the latter mode should be that PRINT statement values would only be shown when a full batch executes, but that can easily be tuned by the user with appropriate amount of GO statements. In my opinion such a change gives more control to the user, and the default of the option would keep us backwards compatible.
I've received requests for
pytsqlto support the @@ROWCOUNT variable, so that print statements of the number of affected rows can be used. An example usage would be:The reason this doesn't work at the moment seems to be that if we don't send both statements in a single "batch" towards the SQL server, the variable gets reset. The current implementation of pytsql separates all top-level statements and sends them separately.
My suggestion would be to introduce an option along the lines of "isolate-top-level-statements" which is true by default and when enabled would retain the current behavior of the tool. However, when disabled, the batching would be done in whole groups inbetween
GOcommands. In this way users who want to use such "context-sensitive" commands can use the latter mode. The only downside of the latter mode should be that PRINT statement values would only be shown when a full batch executes, but that can easily be tuned by the user with appropriate amount ofGOstatements. In my opinion such a change gives more control to the user, and the default of the option would keep us backwards compatible.