Re: DBI version 2
H.Merijn Brand wrote: Tim Bunce wrote: A. What changes you'd like to see in the DBI API. How about a new attribute: AutoTruncate so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it will store "grk" That happens anyway in DBD::Informix - the DBMS does it. There is a warning raised, but the operation goes through anyway. Which DBMS doesn't do that automatically? Ingres? -- Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
Tim Bunce wrote:
>here's another release candidate:
>
> http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040112.tar.gz
Some results I'm sure about:
(Still trying to work out what happened on the Solaris build; best guess so
far is I had a Makefile.old that I'd modified to use $ORACLE_HOME/lib32 from
the previous release candidate. Makefile.PL runs the Makefile.old in
$opts{PREOPT} and so influenced the build process).
Linux, Oracle 9.2.0.4 client & server, Perl 5.8.2, DBI 1.40:
NLS_LANG=ENGLISH_UNITED KINGDOM.WE8ISO8859P15
Build: OK
Tests:
t/base...ok
t/cursor.ok
t/generalok
t/long...ok
t/meta...ok
t/ph_typeNOK 12 expected 'trailing' but got 'trailing ' for VARCHAR2
t/ph_typeFAILED test 12
Failed 1/19 tests, 94.74% okay
t/plsql..ok
t/reauth.skipped
all skipped: no reason given
t/select.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/ph_type.t 191 5.26% 12
1 test skipped.
Windows, Oracle 9.2.0.4 client, 9.2.0.4 Linux server, ActiveState Perl
5.8.2, DBI 1.40:
NLS_LANG=ENGLISH_UNITED KINGDOM.WE8MSWIN1252
(in registry, not environment variable)
Build: OK
Tests:
t\base...ok
t\cursor.ok
t\generalok
t\long...ok
t\meta...ok
t\ph_typeok 11/19 expected 'trailing' but got 'trailing ' for VARCHAR2
t\ph_typeFAILED test 12
Failed 1/19 tests, 94.74% okay
t\plsql..ok
t\reauth.skipped
all skipped: no reason given
t\select.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\ph_type.t 191 5.26% 12
1 test skipped.
Failed 1/9 test scripts, 88.89% okay. 1/1535 subtests failed, 99.93% okay.
Cygwin, Oracle 9.2.0.4 client, Perl 5.8.2, DBI 1.40:
(Although I don't use this much, I use the ActiveState Perl if on Windows,
and this is the first time I've tried building DBD::Oracle on it)
Build: Failed
[EMAIL PROTECTED] /cygdrive/d/Temp/DBD-Oracle-1.15
$ make
cp Oracle.pm blib/lib/DBD/Oracle.pm
cp oraperl.ph blib/lib/oraperl.ph
cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h
cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h
cp Oraperl.pm blib/lib/Oraperl.pm
cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h
cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm
cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm
/usr/bin/perl.exe -p -e "s/~DRIVER~/Oracle/g"
/usr/lib/perl5/site_perl/5.8.2/cyg
win-thread-multi-64int/auto/DBI/Driver.xst > Oracle.xsi
/usr/bin/perl.exe /usr/lib/perl5/5.8.2/ExtUtils/xsubpp -typemap
/usr/lib/perl5/ 5.8.2/ExtUtils/typemap -typemap typemap
Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c
gcc -c -Id:/Oracle/Ora92/oci/include -Id:/Oracle/Ora92/rdbms/demo -I/usr/li
b/pe
rl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/DBI -DPERL_USE_SAFE_PUTEN
V -f
no-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"1.15\" -DXS_VERSION=\"1.
15\"
"-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" -DUTF8_SUPPORT
Oracle .c
gcc -c -Id:/Oracle/Ora92/oci/include -Id:/Oracle/Ora92/rdbms/demo -I/usr/li
b/pe
rl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/DBI -DPERL_USE_SAFE_PUTEN
V -f
no-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"1.15\" -DXS_VERSION=\"1.
15\"
"-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" -DUTF8_SUPPORT
dbdimp .c
dbdimp.c: In function `ora_db_login6':
dbdimp.c:307: warning: cast to pointer from integer of different size
dbdimp.c:317: warning: cast to pointer from integer of different size
dbdimp.c:321: warning: cast to pointer from integer of different size
dbdimp.c:325: warning: cast to pointer from integer of different size
dbdimp.c: In function `dbd_rebind_ph_char':
dbdimp.c:1145: warning: cast from pointer to integer of different size
gcc -c -Id:/Oracle/Ora92/oci/include -Id:/Oracle/Ora92/rdbms/demo -I/usr/li
b/pe
rl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/DBI -DPERL_USE_SAFE_PUTEN
V -f
no-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"1.15\" -DXS_VERSION=\"1.
15\"
"-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" -DUTF8_SUPPORT
oci7.c
gcc -c -Id:/Oracle/Ora92/oci/include -Id:/Oracle/Ora92/rdbms/demo -I/usr/li
b/pe
rl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/DBI -DPERL_USE_SAFE_PUTEN
V -f
no-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"1.15\" -DXS_VERSION=\"1.
15\"
"-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" -DUTF8_SUPPORT
oci8.c
Running Mkbootstrap for DBD::Oracle ()
chmod 644 Oracle.bs
rm -f blib/arch/auto/DBD/Oracle/Oracle.dll
LD_RUN_PATH="d:/Oracle/Ora92/lib:d:/Oracle/Ora92/rdbms/lib"
ld2 -s -L/usr/local /lib Oracle.o dbdimp.o oci7.o oci8.o -o
blib/arch/auto/DBD
Re: Conformance test script for drivers
Umm, maybe I'm misunderstanding you but I looked at 11-dbi-dbh.t http://search.cpan.org/src/HMBRAND/DBD-Unify-0.26/t/11-dbi-dbh.t and it seems full of unify specifics. What's needed is for someone (us) to *design* a scheme for the infrastructure of a DBD test harness. The key part being how an individual driver can communicate to the test harness what SQL it can use and, in some cases, what to expect back. I think a good approach to that would be to use a DBI subclass, say DBI::Test, and the AnyDBD mechanism (that's now part of the DBI but undocumented) so we could have DBI::Test:: subclasses of DBI::Test. That way the $dbh and $sth's are not only DBI handles but also have extra methods that the tests can use to guide their progress. Once those basics are in place it should be straight-forward for people to add tests. Any volunteers to work on this? Tim. On Tue, Jan 13, 2004 at 04:04:14PM +0100, H.Merijn Brand wrote: > On Tue 13 Jan 2004 15:59, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote: > > On Tue 13 Jan 2004 15:45, Tim Bunce <[EMAIL PROTECTED]> wrote: > > > On Mon, Jan 12, 2004 at 08:42:12AM -0800, Dean Arnold wrote: > > > > Maybe a conformance test script for driver writers ? > > > > (or at least a template version...) > > > > > > That's a wonderful goal - but it's not specifically on my list. > > > I just don't have the time. > > > > > > I'd fully support anyone who wants to work on such a thing. > > > It is urgently needed. > > > > FWIW I started with that for DBD::Unify when I was still at DBI-1.14 > > > > l1:/pro/3gl/CPAN/DBD-Unify-0.27 102 > ll t > > total 42 > > 71024 drwxr-xr-x2 merijn softwr 2048 Aug 28 14:46 . > > 57486 drwxr-xr-x4 merijn softwr 2048 Dec 9 16:40 .. > > 71029 -rwxr-xr-x1 merijn softwr841 Oct 23 2000 01-base.t > > 74019 -rwxr-xr-x1 merijn softwr843 Apr 12 2001 02-connect.t > > 71027 -rwxr-xr-x1 merijn softwr 1495 Jul 20 2001 03-general.t > > 71028 -rwxr-xr-x1 merijn softwr122 Oct 23 2000 04-long.t > > 71025 -rwxr-xr-x1 merijn softwr 1259 Oct 23 2000 05-reauth.t > > 76794 -rwxr-xr-x1 merijn softwr 2550 Mar 14 2003 10-dbi-drv.t > > 71041 -rwxr-xr-x1 merijn softwr 2404 Aug 28 14:15 11-dbi-dbh.t > >6381 -rwxr-xr-x1 merijn softwr 1473 Apr 12 2001 12-dbi-sth.t > > 69009 -rwxr-xr-x1 merijn softwr 7851 Aug 28 14:15 20-uni-basic.t > > 70413 -rwxr-xr-x1 merijn softwr 2240 Aug 28 14:16 21-uni-regex.t > > 94019 -rwxr-xr-x1 merijn softwr 1868 Jul 25 2001 27-uni-max.t > > 145940 -rwxr-xr-x1 merijn softwr 1269 Feb 21 2003 30-reconnect.t > > 81344 -rwxr-xr-x1 merijn softwr142 Jul 25 2001 99-done.t > > l1:/pro/3gl/CPAN/DBD-Unify-0.27 103 > > > > > 01 .. 12 are (or at least should be) completely database independant tests. > > Just change the login and you're done > > And all not-yet-implemented DBI features/attributes should be marked # TODO :) > > -- > H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) > using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, > WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify > ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ >
RE: Announce: Release Candidate of DBD::Oracle 1.15 available
>> Works on Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7, except the >> LONG issue: >> >> t\base...ok >> t\cursor.ok >> t\generalok >> t\long...ok 59/372# failed test 60 at line 328. t\long...ok >> 61/372# failed test 68 at line 328. > >New bug triggered by NLS lang I think. What are your NLS settings? > >Can anyone else reporting problems *or* success with DBD::Oracle please let me know your NLS settings. Thanks. Success, 9.2.0.4, MSWin32, 5.8.2 NLS_LANGUAGE = AMERICAN SQL> select * from nls_session_parameters; PARAMETER VALUE -- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CALENDAR GREGORIAN NLS_DATE_FORMATDD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMATHH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM PARAMETER VALUE -- NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMATDD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCPFALSE Jeff
RE: DBI version 2 - 3 API change suggestions
> From: Henrik Tougaard <[EMAIL PROTECTED]> > To: 'Tim Bunce' <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: RE: DBI version 2 - 3 API change suggestions > > 1) > The Ingres Open/API has the possibility of doing > async db-access, ie starting a database request > and then at a later point in time either waiting > for it to complete or just checking if it is > completed yet. > It doesn't support threads (as far as I can see) > or at least the DBD-layer would have to do some > nifty footwork to support it. > I don't know what the DBI API for this kind of > functionality should be, but I think that it > should at least be considered. I'd 2nd that motion. DBD::Teradata has a FirstAvailable()/Realize() driver-specific API to do this. Presumably, ODBC's async model would the basis of DBI's API ? Threads are good, but given the number of sites I see running Perl 5.003, I reckon 5.8.2+ may not propagate quite as quickly as we might like... and some platforms don't support threads well/at all. Dean Arnold Presicient Corp. www.presicient.com
RE: CVS Repository for DBI (was RE: DBI version 2)
> > On Mon, Jan 12, 2004 at 05:53:00PM -0500, Jeff Urlwin wrote: > > > Plans: > > > > > > 1. Move DBI source code to http://sourceforge.net/projects/dbi/ > > > > Tim, > > > > On and Off I've thought about moving DBD::ODBC to a CVS > repository and > > searched for a tool that would take old tarballs of prior > releases and > > build the CVS repository from the tarballs. Maybe I don't need to, > > but it would be nice to have all the versions in a repository, each > > version/release tagged with the release. I just haven't > gotten around > > to it. Would you want to put your history in CVS or just > handle it as > > a "from here on" repository? > > Keeping the history would be nice - but it's not essential. > If I don't get it into CVS then I'd probably tar up my RCS > files and put them on CPAN (or at least backpan) "for posterity". Actually, from what I understand is that cvs import can do it (thanks to Jeffrey W. Baker, who saw this thread and commented to me, as per below: > > > > for release in DBD-ODBC-*; do > > cd $release; > > rev=`echo $release | perl -pe 's/^DBD-ODBC-//'`; > > cvsrev=`echo $rev | perl -pe 's/\./_/g`; > > cvs import -m "DBD::ODBC release $rev" dbd::odbc > > JURLWIN $cvsrev; > > cd ..; > > done; > > I didn't think IMPORT would do what I want. What I want is one > module, DBD-ODBC, which has all revisions in it. cvs import will do what you want. Each release will have its own revision tag as $cvsrev in the above script. I use this method to update my local copy when upstream sources release new revisions. Then I can merge in my local changes to the HEAD branch. In your case of course upstream and local will be the same. Naturally, someone wrote lengthy documentation for CVS already. Tracking third-party sources: http://www.loria.fr/~molli/cvs/doc/cvs_13.html#SEC98 > > > Also, I thought there was a CVS repository specifically > setup for perl > > modules, but I can't seem to find my reference to it. > Wouldn't that > > be "better"? > > Quite possibly. I don't know yet. I'm talking to Rob and Ask, > the perl.org admins, about it. Yes, Rob is the one that I had "discussed" this with a while back ... Either way, if you have DBI and DBD::Oracle hosted somewhere, I will follow suit. > > > Either way, I know I have been interested in setting up a > repository > > for DBD::ODBC, but just haven't found the time. I suppose > It's more > > useful for DBI and the more-used modules (or for the > modules with more > > regular contributions), than for DBD::ODBC. > > Perhaps. But having cvs can also lead to more regular > contributions. At least I certainly hope so :-) Me too. And, to answer your parrot question, I'll help in whatever way I can. Regards, Jeff
Re: commit vs rollback on $dbh->{AutoCommit} = 1 ?
On 1/13/04 2:05 AM, Jonathan Leffler wrote: > Dean Arnold wrote: >> On a related note, is there a need/desire for a std. readonly connection >> attribute to determine if the connection is currently in a transaction ? Yes! I have written more DBI wrappers in my day than I care to remember, and nearly all of them had a "am I in a transaction now?" flag. -John
Re: Conformance test script for drivers
On Tue 13 Jan 2004 15:59, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote: > On Tue 13 Jan 2004 15:45, Tim Bunce <[EMAIL PROTECTED]> wrote: > > On Mon, Jan 12, 2004 at 08:42:12AM -0800, Dean Arnold wrote: > > > Maybe a conformance test script for driver writers ? > > > (or at least a template version...) > > > > That's a wonderful goal - but it's not specifically on my list. > > I just don't have the time. > > > > I'd fully support anyone who wants to work on such a thing. > > It is urgently needed. > > FWIW I started with that for DBD::Unify when I was still at DBI-1.14 > > l1:/pro/3gl/CPAN/DBD-Unify-0.27 102 > ll t > total 42 > 71024 drwxr-xr-x2 merijn softwr 2048 Aug 28 14:46 . > 57486 drwxr-xr-x4 merijn softwr 2048 Dec 9 16:40 .. > 71029 -rwxr-xr-x1 merijn softwr841 Oct 23 2000 01-base.t > 74019 -rwxr-xr-x1 merijn softwr843 Apr 12 2001 02-connect.t > 71027 -rwxr-xr-x1 merijn softwr 1495 Jul 20 2001 03-general.t > 71028 -rwxr-xr-x1 merijn softwr122 Oct 23 2000 04-long.t > 71025 -rwxr-xr-x1 merijn softwr 1259 Oct 23 2000 05-reauth.t > 76794 -rwxr-xr-x1 merijn softwr 2550 Mar 14 2003 10-dbi-drv.t > 71041 -rwxr-xr-x1 merijn softwr 2404 Aug 28 14:15 11-dbi-dbh.t >6381 -rwxr-xr-x1 merijn softwr 1473 Apr 12 2001 12-dbi-sth.t > 69009 -rwxr-xr-x1 merijn softwr 7851 Aug 28 14:15 20-uni-basic.t > 70413 -rwxr-xr-x1 merijn softwr 2240 Aug 28 14:16 21-uni-regex.t > 94019 -rwxr-xr-x1 merijn softwr 1868 Jul 25 2001 27-uni-max.t > 145940 -rwxr-xr-x1 merijn softwr 1269 Feb 21 2003 30-reconnect.t > 81344 -rwxr-xr-x1 merijn softwr142 Jul 25 2001 99-done.t > l1:/pro/3gl/CPAN/DBD-Unify-0.27 103 > > > 01 .. 12 are (or at least should be) completely database independant tests. > Just change the login and you're done And all not-yet-implemented DBI features/attributes should be marked # TODO :) -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Conformance test script for drivers
On Tue 13 Jan 2004 15:45, Tim Bunce <[EMAIL PROTECTED]> wrote: > On Mon, Jan 12, 2004 at 08:42:12AM -0800, Dean Arnold wrote: > > Maybe a conformance test script for driver writers ? > > (or at least a template version...) > > That's a wonderful goal - but it's not specifically on my list. > I just don't have the time. > > I'd fully support anyone who wants to work on such a thing. > It is urgently needed. FWIW I started with that for DBD::Unify when I was still at DBI-1.14 l1:/pro/3gl/CPAN/DBD-Unify-0.27 102 > ll t total 42 71024 drwxr-xr-x2 merijn softwr 2048 Aug 28 14:46 . 57486 drwxr-xr-x4 merijn softwr 2048 Dec 9 16:40 .. 71029 -rwxr-xr-x1 merijn softwr841 Oct 23 2000 01-base.t 74019 -rwxr-xr-x1 merijn softwr843 Apr 12 2001 02-connect.t 71027 -rwxr-xr-x1 merijn softwr 1495 Jul 20 2001 03-general.t 71028 -rwxr-xr-x1 merijn softwr122 Oct 23 2000 04-long.t 71025 -rwxr-xr-x1 merijn softwr 1259 Oct 23 2000 05-reauth.t 76794 -rwxr-xr-x1 merijn softwr 2550 Mar 14 2003 10-dbi-drv.t 71041 -rwxr-xr-x1 merijn softwr 2404 Aug 28 14:15 11-dbi-dbh.t 6381 -rwxr-xr-x1 merijn softwr 1473 Apr 12 2001 12-dbi-sth.t 69009 -rwxr-xr-x1 merijn softwr 7851 Aug 28 14:15 20-uni-basic.t 70413 -rwxr-xr-x1 merijn softwr 2240 Aug 28 14:16 21-uni-regex.t 94019 -rwxr-xr-x1 merijn softwr 1868 Jul 25 2001 27-uni-max.t 145940 -rwxr-xr-x1 merijn softwr 1269 Feb 21 2003 30-reconnect.t 81344 -rwxr-xr-x1 merijn softwr142 Jul 25 2001 99-done.t l1:/pro/3gl/CPAN/DBD-Unify-0.27 103 > 01 .. 12 are (or at least should be) completely database independant tests. Just change the login and you're done 20 and or are Unify specific Help yourself. > Tim. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ tests.tgz Description: Binary data
Re: DBI version 2
On Tue 13 Jan 2004 15:42, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 12, 2004 at 04:59:38PM +0100, H.Merijn Brand wrote:
> >
> > > B. What changes you'd like to see in the DBD API
> > > (that's the DBI<->DBD interface).
> >
> > · All dbh handel offspring (statement handles and such)
> > available from the top level handle, for both status
> > and cleanup purposes
>
> Yeap. A weakref cache is on the list.
Good!
> > · Generic (DBI level) possibility to enable DBD debugging
> > I enabled $dbh->{DBDverbose}, to be the DBD counterpart
> > of DBI::trace (), and later renamed that - on Tim's
> > request - to $dbh->{uni_verbose}, but IMHO the usefulness
> > warrants a high level attribute
>
> A reorg of how TraceLevel works is on the list. You may remember me
> posting about that some months ago. Having an 8bit (max) trace level
> and then 16bits for specific topics and 8bits spare for driver topics.
I remember, but I wanted to stress this. It's important for me (and my
misbehaving database drivers - DBI and DBD do OK)
Example:
bug report: I cannot open blahdieblah, because I get an
undocumented error -273
answer: That seems to be a programming error. In this
case you can ignore it
> Tim.
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
On Tue, Jan 13, 2004 at 09:17:51AM +0100, Steffen Goeldner wrote: > Tim Bunce wrote: > > > > Almost 4 months after the previous release candidate, and 10 months after > > the last full release, here's another release candidate: > > > >http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040112.tar.gz > > Works on Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7, > except the LONG issue: > > t\base...ok > t\cursor.ok > t\generalok > t\long...ok 59/372# failed test 60 at line 328. > t\long...ok 61/372# failed test 68 at line 328. New bug triggered by NLS lang I think. What are your NLS settings? Can anyone else reporting problems *or* success with DBD::Oracle please let me know your NLS settings. Thanks. Tim.
Conformance test script for drivers
On Mon, Jan 12, 2004 at 08:42:12AM -0800, Dean Arnold wrote: > Maybe a conformance test script for driver writers ? > (or at least a template version...) That's a wonderful goal - but it's not specifically on my list. I just don't have the time. I'd fully support anyone who wants to work on such a thing. It is urgently needed. Tim.
Re: DBI version 2
On Mon, Jan 12, 2004 at 04:59:38PM +0100, H.Merijn Brand wrote:
>
> > B. What changes you'd like to see in the DBD API
> > (that's the DBI<->DBD interface).
>
> · All dbh handel offspring (statement handles and such)
> available from the top level handle, for both status
> and cleanup purposes
Yeap. A weakref cache is on the list.
> · Generic (DBI level) possibility to enable DBD debugging
> I enabled $dbh->{DBDverbose}, to be the DBD counterpart
> of DBI::trace (), and later renamed that - on Tim's
> request - to $dbh->{uni_verbose}, but IMHO the usefulness
> warrants a high level attribute
A reorg of how TraceLevel works is on the list. You may remember me
posting about that some months ago. Having an 8bit (max) trace level
and then 16bits for specific topics and 8bits spare for driver topics.
Tim.
Re: CVS Repository for DBI (was RE: DBI version 2)
On Mon, Jan 12, 2004 at 05:53:00PM -0500, Jeff Urlwin wrote: > > Plans: > > > > 1. Move DBI source code to http://sourceforge.net/projects/dbi/ > > Tim, > > On and Off I've thought about moving DBD::ODBC to a CVS repository and > searched for a tool that would take old tarballs of prior releases and build > the CVS repository from the tarballs. Maybe I don't need to, but it would > be nice to have all the versions in a repository, each version/release > tagged with the release. I just haven't gotten around to it. Would you > want to put your history in CVS or just handle it as a "from here on" > repository? Keeping the history would be nice - but it's not essential. If I don't get it into CVS then I'd probably tar up my RCS files and put them on CPAN (or at least backpan) "for posterity". > Also, I thought there was a CVS repository specifically setup for perl > modules, but I can't seem to find my reference to it. Wouldn't that be > "better"? Quite possibly. I don't know yet. I'm talking to Rob and Ask, the perl.org admins, about it. > Either way, I know I have been interested in setting up a repository for > DBD::ODBC, but just haven't found the time. I suppose It's more useful for > DBI and the more-used modules (or for the modules with more regular > contributions), than for DBD::ODBC. Perhaps. But having cvs can also lead to more regular contributions. At least I certainly hope so :-) Tim.
RE: DBI version 2 - 3 API change suggestions
Tim Bunce skrev: > A. What changes you'd like to see in the DBI API. > > B. What changes you'd like to see in the DBD API > (that's the DBI<->DBD interface). > 1) The Ingres Open/API has the possibility of doing async db-access, ie starting a database request and then at a later point in time either waiting for it to complete or just checking if it is completed yet. It doesn't support threads (as far as I can see) or at least the DBD-layer would have to do some nifty footwork to support it. I don't know what the DBI API for this kind of functionality should be, but I think that it should at least be considered. 2) Better support for transactions. At some point I predict that the RDBMS vendors will come up with transaction handles, and we need somewhere to hold them - I foresee several concurrent transactions on the same database handle. 3) A way of getting all active children from a handle, eg all active $sth's in a $dbh. This is usefull when doing something potentially nasty to the $dbh (eg. committing or disconnecting) and you need to do something to all $sth's before - the only way out nnow is to error out with a suitable message to the user, and let them do whatever has to be done. > And, looking further ahead... > > C. How interested/motivated you are in working on a DBD for Parrot. I would love to find the tuits to do that. A good excuse to learn some parrot at last, after lurking on the mailinglists for years. -- Henrik Tougaard, DBD::Ingres.
Re: DBI, DBD::ADO and SUCCESS_WITH_INFO
On Tue, Jan 13, 2004 at 12:35:07PM +0100, Steffen Goeldner wrote:
>
> Tim Bunce wrote:
>
> > My current plan is to add a $h->{HandleEvent} = sub { ... }
> > hook that can be used for SUCCESS_WITH_INFO and other events the
> > driver may want to communicate back to an application.
> >
> > Meanwhile I suggest that you add a $h->{ado_event} = sub { ... }
> > and and use that however you think best. Your experience can feed
> > back into the HandleEvent design.
>
> O.k., but set_err() - how about that (for now)?
> Should it be called or not? Or should it be called with
> err == 0, which makes errstr and state accessible (if not
> overwritten with the next error), but doesn't trigger the
> normal DBI error handling mechanisms?
Umm, yes, normally $h->err ($DBI::err) is undef. Setting it to
0 to indicate info or warning but not an error is a good idea.
Setting errstr and state to non-false values at the same time
has the slight risk that it'll affect code that uses $h->errstr
(or $DBI::errstr) to check for errors. But that's a slight risk.
If no one has a good objection I'll document this (err being 0
instead of undef and errstr and state being set) as the preferred
way to signal info/warning conditions.
Thanks!
Tim.
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
--- Tim Bunce <[EMAIL PROTECTED]> wrote: > On Mon, Jan 12, 2004 at 05:48:48PM -0500, Jeff Urlwin wrote: > > > > > > > > Almost 4 months after the previous release candidate, and 10 > > > months after the last full release, here's another release candidate: > > > > > > > > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040 > > > 112.tar.gz > > > > Works ok on Oracle 9.2.0.4.0 on Solaris (32 bit) except the varchar > trimming > > issue, which has been discussed here before. > > > > t/ph_typeok 11/19 expected 'trailing' but got 'trailing ' for > VARCHAR2 > > t/ph_typeFAILED test 12 > > Failed 1/19 tests, 94.74% okay > > Um, Andy, you didn't mention that one in your "Solaris 2.7 / 9.2.0.4 / > 32-bit" > results. Did you see that? Hm, I'm trying to compile it again and I'm now hitting the 32/64 bit problem again. You'd better ignore my results until I work out what I've done - sorry. It _does_ link if I use '-l' when running Makefile.PL though - but I'm sure I didn't do that the first time. What's puzzling me is that the 1.15 I built yesterday and installed into a test directory is correctly linked against $ORACLE_HOME/lib32. Also; whilst the server I was testing against was 9.2.0.4, the client it was compiled against turns out to be 9.2.0.1 which is probably why ph_type passes. = -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space | disk usage analysis tool Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Re: DBI version 2
On Mon 12 Jan 2004 16:59, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote: > > A. What changes you'd like to see in the DBI API. > > Me and my colleages seem very satisfied :) How about a new attribute: AutoTruncate so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it will store "grk" -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: commit vs rollback on $dbh->{AutoCommit} = 1 ?
On Mon, 2004-01-12 at 10:26, Tim Bunce wrote:
> In his announcement for DBD::Ingres-0.51 Henrik says:
>
> > The DBI docs state that swtiching the value of $dbh->{AutoCommit} from off
> > to on should cause a $dbh->commit to be called, but setting
> > $dbh->{ing_rollback} to on will cause a $dbh->rollback to be called instead.
> >
> > This is mainly usefull in situations where you normally have
> > $dbh->{AutoCommit}=1 and only in some subroutines change it to
> > $dbh->{AutoCommit}=0 using
> >local $dbh->{AutoCommit}=0;
> > to get it reverted to normal use no matter how you leave the subroutine.
> > In these cases it seems much more sensible to rollback any uncommited
> > transactions on resetting AutCommit than to have them commited.
>
> That seems like a very valid point to me. Commits should always be
> explicit not implicit. As it stands now this is very unsafe:
>
> $dbh->{RaiseError} = 1;
> eval {
> local $dbh->{AutoCommit} = 0;
> ...
> }
>
> What to others think of this issue? (Please ignoring for the moment
> any backwards compatibility issues with changing this and focus on the
> principle.)
>
> Tim.
I think commits should always be explicit. I go out of my way to ensure
that that is the behavior I get. Furher, I have never seen a well
written application the understood the scope of its transaction, that
used auto commit behavior, (and I'm not sure its possible to write one)
:-)
Lincoln
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
On Mon, 2004-01-12 at 14:57, Andy Hassall wrote: > Didn't get much time to test it on actual scripts today, but 1.15-rc2 built > and tested OK on Solaris 2.7 / 9.2.0.4 / 32-bit - the build problems from > 1.14 appear to be fixed. I did not get to my solaris 2.8 / oracle 9.2.04 test I promised today. But this is sufficiently close to mine, that I would not hold up for my results. I will try to get to it tomorrow in any case. Lincoiln
Re: DBI, DBD::ADO and SUCCESS_WITH_INFO
Tim Bunce wrote:
> My current plan is to add a $h->{HandleEvent} = sub { ... }
> hook that can be used for SUCCESS_WITH_INFO and other events the
> driver may want to communicate back to an application.
>
> Meanwhile I suggest that you add a $h->{ado_event} = sub { ... }
> and and use that however you think best. Your experience can feed
> back into the HandleEvent design.
O.k., but set_err() - how about that (for now)?
Should it be called or not? Or should it be called with
err == 0, which makes errstr and state accessible (if not
overwritten with the next error), but doesn't trigger the
normal DBI error handling mechanisms?
Steffen
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
On Tue, Jan 13, 2004 at 09:17:51AM +0100, Steffen Goeldner wrote: > Tim Bunce wrote: > > > > Almost 4 months after the previous release candidate, and 10 months after > > the last full release, here's another release candidate: > > > >http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040112.tar.gz > > Works on Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7, > except the LONG issue: > > t\base...ok > t\cursor.ok > t\generalok > t\long...ok 59/372# failed test 60 at line 328. > t\long...ok 61/372# failed test 68 at line 328. > t\long...ok 66/372# failed test 76 at line 328. > t\long...ok 75/372# failed test 86 at line 342. > # failed test 88 at line 342. > # failed test 90 at line 342. > t\long...ok 137/372# failed test 153 at line 328. > t\long...ok 146/372# failed test 161 at line 328. > t\long...ok 156/372# failed test 169 at line 328. > t\long...ok 164/372# failed test 179 at line 342. > # failed test 181 at line 342. > t\long...ok 172/372# failed test 183 at line 342. > t\long...ok 343/372 > Some tests for LONG data type handling failed. These are generally Oracle bugs. Odd. I thought those had (eventually) been nailed down to a coding bug that had been patched. Please send (just) me the output of "perl -Mblib t/long.t" and perl -V and, ideally, a log of the whole build process. Thanks. Tim.
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
On Mon, Jan 12, 2004 at 05:48:48PM -0500, Jeff Urlwin wrote: > > > > > Almost 4 months after the previous release candidate, and 10 > > months after the last full release, here's another release candidate: > > > > > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040 > > 112.tar.gz > > Works ok on Oracle 9.2.0.4.0 on Solaris (32 bit) except the varchar trimming > issue, which has been discussed here before. > > t/ph_typeok 11/19 expected 'trailing' but got 'trailing ' for VARCHAR2 > t/ph_typeFAILED test 12 > Failed 1/19 tests, 94.74% okay Um, Andy, you didn't mention that one in your "Solaris 2.7 / 9.2.0.4 / 32-bit" results. Did you see that? Tim.
RE: commit vs rollback on $dbh->{AutoCommit} = 1 ?
Dean Arnold skrev:
> On a related note, is there a need/desire
> for a std. readonly connection attribute to
> determine if the connection is currently
> in a transaction ?
>
> E.g.,
>
> $dbh->commit()
> if $dbh->{InTransaction};
Yes, please in Ingres it is possible to ask the
DBMS for transaction state, but it wpuld be much
easier to have a attribute for it.
--
Henrik Tougaard
DBD::Ingres
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
Tim Bunce wrote: > > Almost 4 months after the previous release candidate, and 10 months after > the last full release, here's another release candidate: > >http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040112.tar.gz Works on Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7, except the LONG issue: t\base...ok t\cursor.ok t\generalok t\long...ok 59/372# failed test 60 at line 328. t\long...ok 61/372# failed test 68 at line 328. t\long...ok 66/372# failed test 76 at line 328. t\long...ok 75/372# failed test 86 at line 342. # failed test 88 at line 342. # failed test 90 at line 342. t\long...ok 137/372# failed test 153 at line 328. t\long...ok 146/372# failed test 161 at line 328. t\long...ok 156/372# failed test 169 at line 328. t\long...ok 164/372# failed test 179 at line 342. # failed test 181 at line 342. t\long...ok 172/372# failed test 183 at line 342. t\long...ok 343/372 Some tests for LONG data type handling failed. These are generally Oracle bugs. Please report this to the dbi-users mailing list, and include the Oracle version number of both the client and the server. Please also include the output of the 'perl -V' command. (If you can, please study t/long.t to investigate the cause. Feel free to edit the tests to see what's happening in more detail. Especially by adding trace() calls around the failing tests. Run the tests manually using the command "perl -Mblib t/long.t") Meanwhile, if the other tests have passed you can use DBD::Oracle. t\long...FAILED tests 60, 68, 76, 86, 88, 90, 153, 161, 169, 179, 181, 183 Failed 12/372 tests, 96.77% okay t\meta...ok t\ph_typeok t\plsql..ok t\reauth.skipped test on this platform t\select.ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t\long.t 372 12 3.23% 60 68 76 86 88 90 153 161 169 179 181 183 1 test skipped. Failed 1/9 test scripts, 88.89% okay. 12/545 subtests failed, 97.80% okay. dmake.exe: Error code 32, while making 'test_dynamic' Steffen
Re: commit vs rollback on $dbh->{AutoCommit} = 1 ?
Dean Arnold wrote:
On a related note, is there a need/desire
for a std. readonly connection attribute to
determine if the connection is currently
in a transaction ?
E.g.,
$dbh->commit()
if $dbh->{InTransaction};
I've hacked my own version of this in DBD::Teradata
for an IDE I've built. Granted, its possible for the
app to keep track of xaction state, but given
variations in xaction behavior between various
DBMS's, it might be useful for portablility, e.g.,
$dbh->{AutoCommit} = 0;
...do some SQL...
...an error occurs...
$dbh->rollback() if $dbh->{InTransaction};
Since ANSI usually requires transactions to persist
even when errors occur, but some DBMS's will
rollback on an error, might this useful ?
DBD::Informix has supported $dbh->{ix_InTransaction} since forever (or
1996, which is close enough to forever for the difference not to matter:-)
I'd say yes, in other words.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
#include
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
