I don't use ADO but I do use ODBC. SQL Server normally batches the statements in
a procedure so in ODBC terms for your procedure you have to:
execute
fetchall
SQLMoreResults # moves to the update
rowcount - to get row update count
SQLMoreResults - # moves to the second select
fetchall
Thanks for the feedback everyone. I need to add that I tried another
test. In this one, I pulled out the insert and update statement from the
SP (just to confirm that what I wanted to do really would work) and the
result set was returned and the fetchrow_array call did succeed and
returned my
On a Solaris system, we recently had our database moved to a
new box, newer Oracle version (9-something). Our client
software is still 8.1.6. What we're seeing are cases where
the database goes down, and we don't always see the expected
ORA-03113 error, whereas before, that error always caused
I'm able to install DBD::ODBC 1.11, however, I can not install 1.12 or
1.13. Following is a complete log of the steps used to build 1.13. If
anybody has any idea what might be going on, I would appreciate being
pointed in the right direction.
Thanks,
Jonathan
# make realclean
rm -rf ODBC.c
I'm able to install DBD::ODBC 1.11, however, I can not install 1.12 or
1.13. Following is a complete log of the steps used to build
1.13. If
anybody has any idea what might be going on, I would appreciate being
pointed in the right direction.
Thanks,
Jonathan
# make realclean
t/02simple...1..36
ok 1 - use DBI;
ok 2 - use ODBCTEST;
ok 3 - Set Auto commit
ok 4 - Auto commit retrieved to what was set ok 5 - create test table
ok 6 - test table exists ok 7 - insert test data ok 8 - select test
data ok 9 - Set Long Read len ok 10 - Set Long Truncok 1 ok 11 - Set
From: Martin J. Evans [EMAIL PROTECTED]
I don't use ADO but I do use ODBC. SQL Server normally batches the
statements in a procedure so in ODBC terms for your procedure you have
to:
execute
fetchall
SQLMoreResults # moves to the update
rowcount - to get row update count
SQLMoreResults -
On Mar 2, Jenda Krynicky scribed:
Try to add
SET NOCOUNT ON
on top of the stored procedure. That should prevent the select into
and update statements from getting in the way.
Thanks! That's it. I forgot about that.
Dave
execute ok 26 - group by query returned rows not ok 27 -
data sources
test
# Failed test (t/02simple.t at line 132)
# '0'
#
# '0'
First -- I think it's pretty safe to install this version, unless you
require the use of the data_sources() function.
Ok