select * from (procedure_foo)
That would be lovely, but I can find no way to wrap a procedure in a
select. If it were possible I could have just rewritten the procedure
call as a select and matched the existing regexp.
you can do that as
happily, though, I realized I can create a table-valued function that
executes the procedure, and I
can select from the table-valued function in this way.
Right, table-valued functions were added in MSSQL2000, but they do have some
limitations compared to regular stored procedures - notably,
so, does somebody want to add EXEC to the is_select() regexp ?
I think we should also add a flag to text() which allows this too,
along the lines of returns_results=True.
On Feb 13, 2008, at 4:50 PM, Paul Johnston wrote:
John,
I am using unixodbc-2.2.11 as packaged by Ubuntu 7.10
Sure, I'll take care of it. Is there an easy way to side-step things like
columns named 'exec', or is that just a risk we take?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group,
the regexp is \s*(keywords) so it should only match EXEC as the first
thing in the string.
is the EXEC the only way to call an SP in MS-SQL ? no SELECT
procname ?
On Feb 14, 2008, at 12:05 PM, Rick Morrison wrote:
Sure, I'll take care of it. Is there an easy way to side-step things
Only rarely is there only one way to do something in MSSQL ;-)
Stored procedures can also be called simply by name, omitting the EXEC:
EXEC procedure_foo parms
or
procedure_foo parms
and I believe they can also be called from within a subquery:
select * from
This approach would be ideal, and would work with row-returning functions,
etc. but obviously depends on some rather sophisticated cooperation with
the dbapi. I don't think pymssql would be up to the task, although I think
the ODBC-derived dbapis might work.
On Thu, Feb 14, 2008 at 12:11 PM,
I think we should also add a flag to text() which allows this too,
along the lines of returns_results=True.
+1 on that, it would be useful as a fallback for those oddball situations.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Stored procedures can also be called simply by name, omitting the EXEC:
EXEC procedure_foo parms
or
procedure_foo parms
True, but as you suggested it's hardly a burden to type the EXEC.
and I believe they can also be called from within a subquery:
select *
I think we should also add a flag to text() which allows this too,
along the lines of returns_results=True.
+1 on that, it would be useful as a fallback for those oddball situations.
Indeed, Microsoft SQL Server interprets myriad bespoke SQL
constructs which return results. Perhaps the
Michael Bayer wrote:
so, does somebody want to add EXEC to the is_select() regexp ?
I think we should also add a flag to text() which allows this too,
along the lines of returns_results=True.
There was some talk of trying to auto-detect resultsets with cursor
inspection. My recollection
Rick Morrison wrote:
Only rarely is there only one way to do something in MSSQL ;-)
Stored procedures can also be called simply by name, omitting the EXEC:
EXEC procedure_foo parms
or
procedure_foo parms
True, as long as the call is the first statement in the
Rick Morrison wrote:
This approach would be ideal, and would work with row-returning
functions, etc. but obviously depends on some rather sophisticated
cooperation with the dbapi. I don't think pymssql would be up to the
task, although I think the ODBC-derived dbapis might work.
It's not
And support procedures returning multiple resultsets in general.
That would be great, although I think such things are pretty poor form.
Years ago I worked on a legacy system that had a calc procedure returning
20+ result sets, and a variable number of them at that. What a nightmare
that was
I'm using pyodbc on Unix.
blink You are???
This statement jumped out of the message for me. Can you please describe
your setup to the list? There is a lot of interest in this configuration.
--~--~-~--~~~---~--~~
You received this message because you are
On Feb 13, 2008, at 12:03 PM, John Keith Hohm wrote:
I'm using and loving SQLAlchemy 0.4.3dev_r4136 but I am having a
problem with (drum roll) a legacy database schema. I'm using pyodbc
on Unix.
The primary keys in a legacy table are alphanumeric and must be
generated by a MSSQL stored
I'm using pyodbc on Unix.
blink You are???
This statement jumped out of the message for me. Can you please describe
your setup to the list? There is a lot of interest in this configuration.
I am using unixodbc-2.2.11 as packaged by Ubuntu 7.10 (gutsy) with
locally-installed freetds-0.64
John,
I am using unixodbc-2.2.11 as packaged by Ubuntu 7.10 (gutsy) with
That sounds very promising, I have been meaning to have a go at this for
a while.
Can you do me a favor and run the unit tests using your current setup?
Run alltests.py and append text_as_varchar=1 to the dburi (a
18 matches
Mail list logo
