Re: DBD::ODBC-0.29 developers release
Such releases could, and probably should, go out via CPAN using a version number containing an underscore (so they won't be indexed). Thus: DBD-ODBC-0.32_01.tar.gz Just set the VERSION (in Makefile.PL) or $VERSION (in ODBC.pm) like that and MakeMaker and PAUSE will do the right thing. Tim. On Tue, Sep 04, 2001 at 09:58:44PM -0400, Jeff Urlwin wrote: > ftp://63.76.230.5/pub/perl/DBD-ODBC-0.29.tar.gz > > (beware of slow connect time, I'm still working on why that is...then again, > it could be internal only on the reverse DNS lookup) > > Jeff > > > -Original Message- > > From: Thomas A. Lowery [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, September 04, 2001 7:41 PM > > To: [EMAIL PROTECTED] > > Subject: Re: DBD::ODBC-0.29 developers release > > > > > > Where do download the new DBD::ODBC (developers release)? > > > > Tom > > > > -- > > Thomas A. Lowery > > See DBI/FAQ http://tlowery.hypermart.net > > _ Do You > > Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com > > >
RE: DBD::ODBC-0.29 developers release
Thanks, I got it. The ODBC connection on the server had to be SQL server authentication. There was no error messages coming back from the ODBC driver that said it was failing to change users though. I'll CC this to the developers group so the author can make a note of that. > -Original Message- > From: Thomas A. Lowery [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 05, 2001 2:45 PM > To: Tim Harsch > Subject: Re: DBD::ODBC-0.29 developers release > > > On Wed, Sep 05, 2001 at 12:06:45PM -0700, Tim Harsch wrote: > > Do you know anything about EasySoft ODBC::ODBC bridge? I > thought I saw a > I've worked with it some. > > > couple of posts by you that were related. If so, I may some > questions for > > you, if you don't mind helping a bit. Easysoft support has repeatedly > > ignored my request so I'm struggling. > > I'll help if I can. > > Tom > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > >
RE: DBD::ODBC-0.29 developers release
ftp://63.76.230.5/pub/perl/DBD-ODBC-0.29.tar.gz (beware of slow connect time, I'm still working on why that is...then again, it could be internal only on the reverse DNS lookup) Jeff > -Original Message- > From: Thomas A. Lowery [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 04, 2001 7:41 PM > To: [EMAIL PROTECTED] > Subject: Re: DBD::ODBC-0.29 developers release > > > Where do download the new DBD::ODBC (developers release)? > > Tom > > -- > Thomas A. Lowery > See DBI/FAQ http://tlowery.hypermart.net > _ Do You > Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com >
Re: DBD::ODBC-0.29 developers release
Where do download the new DBD::ODBC (developers release)? Tom -- Thomas A. Lowery See DBI/FAQ http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
DBD::ODBC-0.29 developers release
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
