Sorry for not trying this out sooner but I have been on holiday.
I cannot say I have exhausively tested it but here are a few comments:
[1] dbdimp.c and ODBC.pm appear to be DOS files and so pod2man fails
on them during make (at least it did for me).
[2] In ODBC.pm my name appears to be down as Martin Brimer instead of
Martin Evans (brimer is the name of my machine so I see where it
came from).
[3] The make test ran to MS SQL Server and DB2 fine and some of my own tests
ran fine.
[4] Simple bind_param_inout() to MS SQL Server seems to work fine.
However, what I would have liked to be able to do is get a procedures
return status and I wasn't sure how I could do that. e.g
create proc jenn2 @status integer output as
begin
set @status = 99 return @status
end
works OK when doing:
$sql = qq/ {call jenn2(?)} /;
my $result;
my $sth = $dbh->prepare( $sql );
$result = '1';
$sth->bind_param_inout( 1, \$result, 100);
$sth->execute();
$sth->finish();
print "result = ", $result, "\n";
but if the procedure is defined as:
create proc jenn2 as begin
declare @status integer
set @status = 99
return @status
end
then I cannot work out how to successfully get the return status from
"{? = call jenn2}" as it is only an output parameter and not an input and
output parameter.
I also recollect Jeff saying there was some issue with input/output
parameters and NULLs in Oracle so if anyone can send me the code they were
using to test this I will try that out to MS SQL Server and a few other ODBC
drivers.
[5] I have tried the change submitted by Andrew Brown and I have to admit to
having some reservations with it. If I understand correctly what Andrew was
trying to achieve was multiple active statements in MS SQL Server. i.e. you
can do something like:
#$dbh->{SQL_ROWSET_SIZE} = 2;
my ($sql1, $sql2);
$sql1 = qq/ select * from bench_char /;
$sql2 = qq/ select * from bench_int /;
my $sth1 = $dbh->prepare($sql1);
my $sth2 = $dbh->prepare($sql2);
$sth1->execute();
$sth2->execute();
my @row;
@row = $sth1->fetchrow_array;
print @row, "\n";
@row = $sth2->fetchrow_array;
print @row, "\n";
$sth1->finish();
$sth2->finish();
With the $dbh->{SQL_ROWSET_SIZE} = 2 commented out MS SQL Server returns:
DBD::ODBC::st execute failed: [unixODBC][Microsoft][ODBC SQL Server
Driver]Connection is busy with results for another hstmt (SQL-S1000)(DBD:
st_execute/SQLExecute err=-1) at perl_rowset.pl line 26.
as you would expect but with $dbh->{SQL_ROWSET_SIZE} = 2 uncommented it
works. I suspect this is more by accident than design. My concerns are:
[a] forcing a cursor change could affect the result-set and could in fact
mean the SQL cannot even be executed.
A trivial example would be setting a KEYSET cursor and doing "select
'hello' from table".
[b] There is an assumption that setting SQL_ROWSET_SIZE will have no effect
as SQL_ROWSET_SIZE only applies to SQLExtendedFetch and DBD::ODBC never
calls SQLExtendedFetch. This is potentially flawed as an ODBC driver
manager may map SQLFetch calls to SQLExtendedFetch and SQL_ROWSET_SIZE
is passed through to the driver regardless (i.e. when an ODBC 3.0
application calls an ODBC driver this happens). This could then cause
serious corruption.
I hope this proves helpful.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
