RE: [dbi] RE: 20SqlServer test in DBD::ODBC recommends driver upgrade - why?
Jeff and all, I have managed to dig out a little further information that may prove useful for others. The case we are looking at here produces the following for 20SqlServer test 1 and 2: t/20SqlServer1..25 Inserting: 0, string length 13 Inserting: 1, 2001-01-01 01:01:01.110 string length 12 Inserting: 2, 2002-02-02 02:02:02.123 string length 114 Inserting: 3, 2003-03-03 03:03:03.333 string length 251 Inserting: 4, 2004-04-04 04:04:04.443 string length 282 Inserting: 5, 2005-05-05 05:05:05.557 string length 131 Retrieving: 0, string length 13 Retrieving: 1, 2001-01-01 01:01:00.000 string length 12 !time Retrieving: 2, 2002-02-02 02:02:02.123 string length 114 Retrieving: 3, 2003-03-03 03:03:03.333 string length 251 Retrieving: 4, 2004-04-04 04:04:04.443 string length 282 Retrieving: 5, 2005-05-05 05:05:05.557 string length 131 not ok 1 f ne foo Please upgrade your ODBC drivers to the latest SQL Server drivers available. not ok 2 The first obvious problem is the timestamp 2001-01-01 01:01:01.110 inserted is retrieved as 2001-01-01 01:01:00.000. The second problem is that test 2 inserts foo and gets back f. I have emails with you regarding the second issue which was finally tracked down to a SQL Server problem and an upgrade to MDAC 2.7 fixed it for you (and the person who originally reported it) but I can't find anything regarding the first issue other than the comment in the test that says: the times chosen below are VERY specific to NOT cause rounding errors, but may cause different errors on different versions of SQL Server. For reference the version of the SQL Server driver being used in this case is 2000.80.194.00. A version of the SQL Server driver that works is 2000.81.9030.04. I cannot find anything on MS's site but I can definitely confirm an upgrade of the SQL Server ODBC driver to the one in MDAC 7 fixes the problem. Jeff, you might want to add something to the Please upgrade your ODBC drivers... message to help here or mention the buggy 2000.80.194.00 driver. Martin On 11-Jun-2003 Jeff Urlwin wrote: Hi, Does anyone know why the 20Sqlserver test in DBD::ODBC recommends upgrading your ODBC driver? - Jeff. Err. If I recall correctly, those tests failed with MDAC 2.6 or less and worked with MDAC 2.7. I can't recall why, but I thought I was getting strange responses and when I upgraded, it worked. t/20SqlServerPlease upgrade your ODBC drivers to the latest SQL Server drivers available. FAILED tests 1-2, 6 What was the purpose of the test? It appears to create a temporary table, insert some values and retrieve them again to make sure they are correctly inserted. I am in the process of getting verbose output for the test but if someone knows the reason for the upgrade advice I'd love to know. I wish I remembered more and documented it... Regards, Jeff -- Martin J. Evans Easysoft Ltd, UK Development
(Fwd) Re: [Plezz Help~~] Some error during installing DBD-Oracle-1.12
- Forwarded message from Jenny Kim [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] X-MsgID: 1055415461.19658.mail X-RECEIVED-IP: 203.236.3.209 From: Jenny Kim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Plezz Help~~] Some error during installing DBD-Oracle-1.12 Date: Thu, 12 Jun 2003 19:57:35 +0900 - Original Message - From: Jenny Kim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 7:31 PM Subject: Re: [Plezz Help~~] Some error during installing DBD-Oracle-1.12 Dear Tim, Thanks your advice. Well...I wanna ask some question about installation under HP-UX. I installed perl 5.8 and oracle 9i client(only SQL Net). Then I installed DBI 3.0 (It was sucessfull) and DBD-Oracle-1.12. There were some error message during make command as bellow. But when I installed DBD-Oracle-1.12 on HP-UX installed Oracle 8i server, there was no problem. Can you comment about that for me ? Well...I checked README..somthing...but I can't make it. Thanks in advance. Jenny - Original Message - From: Tim Bunce [EMAIL PROTECTED] Newsgroups: perl.dbi.dev To: Jenny [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 5:39 PM Subject: Re: [Plezz Help~~] Some error during installing DBD-Oracle-1.12 The [EMAIL PROTECTED] mailing list is the best place to ask. The [EMAIL PROTECTED] mailing list is mainly for developers of DBD's. You need to install more Oracle software. See README.clients. Tim. p.s. As you're on HP-UX you're bound to run into several problems. Read the README.hpux file carefully. I aim to release DBD::Oracle 1.15 in the next few days. Watch out for that. On Thu, Jun 12, 2003 at 10:52:38AM +0900, Jenny wrote: hi... guys~ I am a beginner...for Perl.. Pleas someone help me out..it I don't know how to make it.. When I install DBD-Oracle-1.12 at system, it was failed with some error messages, as follows. = cc -c -I/home/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/rdbms/ public -I/home/oracle/OraHome1/plsql/public -I/home/oracle/OraHome1/network/ publ ic -I/home/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/rdbms/demo -I/ opt/ perl5/lib/site_perl/5.8.0/PA-RISC2.0/auto/DBI -Ae -D_HPUX_SOURCE -Wl,+vnoco mpat warnings -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 olimit-DVERSION=\ 1.12\ -DXS_VERSION=\1.12\ +Z -I/opt/perl5/lib/5.8.0/PA-RISC2.0/CORE Ora cle.c cpp: dbdimp.h, line 44: error 4036: Can't open include file 'ocidfn.h'. cpp: dbdimp.h, line 57: error 4036: Can't open include file 'ociapr.h'. *** Error exit code 1 = Installation Environment : HW : HP-UX OS : HP-UX B.11.11 === I'll quite appreciate with your help... Thanks in advance. Jenny - End forwarded message -
Problem with DBD-Oracle 1.14 and Cygwin
I'm trying to compile DBD-Oracle 1.14 on Cygwin, and I'm having a problem that doesn't look like any of the other problems people have talked about. I'm using the Oracle Windows client 9.0.1. Is that a problem? Should I use 9.2? I have a brand new Cygwin install. I noticed its gcc is a strange version, different from the one reported by its perl -V: Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) I get this warning on the make: WARNING: could not decode oracle version from C:/oracle/ora90/orainst/inspdver, or C:/oracle/ora90/install/unix.rgs or from ORACLE_HOME path C:/oracle/ora90. Oracle version based logic in Makefile.PL may produce erroneous results. I haven't actually set ORACLE_HOME, so that path came from the registry. Then, it says this: Found header files in rdbms/demo. * I can't find the header files I need in your Oracle installation. You probably need to install some more Oracle components. I'll keep going, but the compile will probably fail. See README.clients for more information.^G * Found oci directory Using OCI directory 'oci' This is all attached... It doesn't appear to find everything. Then, the make fails, horribly: dbdimp.c: In function `ora_db_login6': dbdimp.c:291: warning: cast to pointer from integer of different size dbdimp.c: In function `pp_exec_rset': dbdimp.c:1193: internal error: Segmentation fault (Which is why I was looking at the gcc versions.) Any ideas? Kevin Using DBI 1.37 installed in /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/auto/DBI Configuring DBD::Oracle ... Remember to actually *READ* the README file! Especially if you have any problems. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/Win32/Registry.pm line 452. Using Oracle in C:/oracle/ora90 WARNING: could not decode oracle version from C:/oracle/ora90/orainst/inspdver, or C:/oracle/ora90/install/unix.rgs or from ORACLE_HOME path C:/oracle/ora90. Oracle version based logic in Makefile.PL may produce erroneous results. Found header files in rdbms/demo. * I can't find the header files I need in your Oracle installation. You probably need to install some more Oracle components. I'll keep going, but the compile will probably fail. See README.clients for more information. * Found oci directory Using OCI directory 'oci' System: perl5.008 cygwin_nt-4.0 iokaste 1.3.22(0.7832) 2003-03-18 09:20 i686 unknown unknown cygwin Compiler: gcc -O3 -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing Linker: /usr/bin/ld Sysliblist: Warning: If you have problems you may need to rebuild perl with -Uusemymalloc. Checking if your kit is complete... Looks good LD_RUN_PATH=/cygdrive/c/build2/DBD-Oracle-1.14 Using DBD::Oracle 1.14. Using DBD::Oracle 1.14. Using DBI 1.37 installed in /usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int/auto/DBI Writing Makefile for DBD::Oracle *** If you
Re: Problem with DBD-Oracle 1.14 and Cygwin
On Thu, Jun 12, 2003 at 11:53:55AM -0400, Kevin White wrote: Then, the make fails, horribly: dbdimp.c: In function `ora_db_login6': dbdimp.c:291: warning: cast to pointer from integer of different size dbdimp.c: In function `pp_exec_rset': dbdimp.c:1193: internal error: Segmentation fault (Which is why I was looking at the gcc versions.) Any ideas? Sure looks like a compiler bug. Tim.
Query formatting problem
I'm trying to find a way of using DBI's internal knowlege of how bind var's are managed to format a working query for error messages. I normally use placeholders with execute or selectall*. This works wonderfully and saves quite a bit of hassles trying to interpolate the queries. Catch is that if the query fails our sysadmin's don't want a placeholder-ized string with some values but a real query they can cut+paste into the system to see what happend. A truncated example (multiple sub-queries removed) is: select foo, bar from some_table where name = ? and value = ? and date = ? run as: $sth-execute( $a, $a, $today ); Yes, $a is used twice, in one case it is compared to a number, the other it used as a string. Using the placeholders makes my life simpler since the name and value are taken from the same variable but DBI handles the stringy/numeric issues for itself. The problem starts when admin's have to check why something failed at 3am and don't know that the '?' are replaced as '500' followed by a naked 500 (for $a) and then the date in quotes. What I need is something like: my $string = $sth-interpolated( $sql, @bindlist ); which called as: my $a = 500; my $date = '11-Jul-1999'; $string = $sth-interpolated( $sql, $a, $a, $date ) gives me back: select foo, bar from some_table where name = 500 and value = 500 and date = 11-Jul-1999 The main issue is being able to walk the bind param. list and check if the columns are numeric (naked copy of $a + 0 inserted) or not (quoted copy of $a). The alternative is having to sprintf every query I use for each combination of values and $dbh-do() them for large datasets in case any one of them fails (ugh!). Looking throught he DBI-1.38 pod, the Catalog Methods don't have anything quite like this since there is no way to query what DBI thinks of the bound parameters (vs. things like column_info which are about the returned data set). An ideal would be some sort of $dbh-blah that returned the stringified version of whatever query was run last: die join \n, 'Bad news, boss:', $dbh-errstr, $dbh-last_query ; If there is someplace w/in the SQL modules that has this please warn me, so far wandering through CPAN hasn't gotten me anywhere. thanx -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 888 359 3508
ActiveState Awards
...Has anybody mentioned that Tim is a nominee??? I just voted for him, nudge nudge, wink wink, say no more, say no more. -- E-Mail: [EMAIL PROTECTED] Date: 12-Jun-2003 Time: 13:20:34 --
Re: Query formatting problem
On Thu, 12 Jun 2003 11:55:05 -0500 Steven Lembark [EMAIL PROTECTED] wrote: I'm trying to find a way of using DBI's internal knowlege of how bind var's are managed to format a working query for error messages. It varies from one DBD driver to another. You don't mention which DBD you are using, so I'm using DBD::Oracle as an example. A truncated example (multiple sub-queries removed) is: select foo, bar from some_table where name = ? and value = ? and date = ? run as: $sth-execute( $a, $a, $today ); Yes, $a is used twice, in one case it is compared to a number, the other it used as a string. That is fine since you have 3 placeholders. Using the placeholders makes my life simpler since the name and value are taken from the same variable but DBI handles the stringy/numeric issues for itself. The problem starts when admin's have to check why something failed at 3am and don't know that the '?' are replaced as '500' followed by a naked 500 (for $a) and then the date in quotes. What I need is something like: my $string = $sth-interpolated( $sql, @bindlist ); which called as: my $a = 500; my $date = '11-Jul-1999'; $string = $sth-interpolated( $sql, $a, $a, $date ) gives me back: select foo, bar from some_table where name = 500 and value = 500 and date = 11-Jul-1999 In Oracle, value and date are reserved words. Name might be too. For DBD::Oracle you really get something like: SELECT foo, bar FROM some_table WHERE name = :1 AND value = :2 AND date = :3 I normally convert that to a SQL*Plus script for testing. That way I am still using bind variables and don't miss problems caused by them. It also makes changing the values easier. From memory and not tested: VARIABLE p1 VARCHAR2 VARIABLE p2 NUMBER VARIABLE p3 DATE BEGIN :p1 := 500; :p2 := 500; :p3 := TO_DATE( '1999-07-11', '-MM-DD' ); END; / SELECT foo, bar FROM some_table WHERE name_c = :p1 AND value_c = :p2 AND date_c = :p3 / The main issue is being able to walk the bind param. list and check if the columns are numeric (naked copy of $a + 0 inserted) or not (quoted copy of $a). The alternative is having to sprintf every query I use for each combination of values and $dbh-do() them for large datasets in case any one of them fails (ugh!). If you don't know what the data types you are comparing to are, you have bigger problems than the query format. -- Mac :}) Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
DBD::Oracle
When we installed using a 32 bit oracle in the past everything was fine. Doing a re-install with Oracle 9 (64bit) is generating these errors, any ideas? Thanks, richardf at san dot rr dot com Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so LD_RUN_PATH=/usr/local/oracle9/lib:/usr/local/oracle9/rdbms/lib /opt/SUNWforte7/SUNWspro/bin/cc -G -L/usr/local/lib Oracle.o dbdimp.o oci7.o oci8.o -L/opt/SUNWcluster/lib -R/opt/SUNWcluster/lib -o build -L/usr/local/oracle9/rdbms/lib/ -L/usr/local/oracle9/lib/ -lclntsh -lnbeq9 -lnhost9 -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 -lnsl -lsocket -lgen -ldl -R/usr/local/oracle9/lib -laio -lposix4 -lkstat -lm -lthread -o blib/arch/auto/DBD/Oracle/Oracle.so ld: fatal: file /usr/local/oracle9/lib//libclntsh.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to blib/arch/auto/DBD/Oracle/Oracle.so *** Error code 1 make: Fatal error: Command failed for target `blib/arch/auto/DBD/Oracle/Oracle.so' /usr/ccs/bin/make -- NOT OK cpan
Help with new DBI::ProxyServer error messages
Heya folks
I've recently upgraded the DBI and DBD packages on a development server,
and I'm now getting some new error messages that are raising some concern.
I found references to recent changes that may reflect this problem, and
I'm wondering how to best handle this:
The error messages (two off), are:
DBI::ProxyServer[10544]: Can't set
DBI::ProxyServer::db=HASH(0x40a5c8)-{Username}: unrecognised attribute or
invalid value at /usr/local/lib/perl5/site_perl/5.8.0/RPC/PlServer.pm line
332.
... and ...
DBI::ProxyServer[10544]: Not permitted for method disconnect of class
DBI::ProxyServer::db at
/usr/local/lib/perl5/site_perl/5.8.0/RPC/PlServer.pm line 328.
with the associated system error message:
Driver has not implemented the disconnect_all method. at
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/DBI.pm line 565
---
Both trace back to the CallMethod routine in PlServer.pm. I found
references to recent changes (the addition of the Username attribute to
the database handles), so I'm wondering if it's still being implemented?
The disconnect method is also peculiar: again, there is a reference to
this call in the Changes Fixed disconnect_all() to not be required by
drivers, but clearly the error message indicates otherwise.
Can anyone help suggest a work around? I should note that despite these
messages, I still appear to get successful connections and data, etc
... from the database, so I guess I can live with it all!?
My many thanks!
J.
___
+-- -++
| John V Cougar __| Voice: +61 2 6208 1683 |
| Cache Manager/ / /\ ++
| Telstra Internet \/_/ \ Direct | E-Mail: [EMAIL PROTECTED] |
+/ ---++
Re: Query formatting problem
In Oracle, value and date are reserved words. Name might be too. snip The main issue is being able to walk the bind param. list and check if the columns are numeric (naked copy of $a + 0 inserted) or not (quoted copy of $a). The alternative is having to sprintf every query I use for each combination of values and $dbh-do() them for large datasets in case any one of them fails (ugh!). If you don't know what the data types you are comparing to are, you have bigger problems than the query format. Actually, one if the nice thigns about bind parameters is that I don't have to know much about the underlying database fields. If 500 is use stringily in one place and numerically in another perl just Does The Right Thing and I don't really care about it. However, this has nothing at all to do with running the queries. I can already run the querys perfectly with placeholders. The placeholders are a pain for admin's, however, since they can not simply paste the queries into the database client shell for later testing if I report errors. It is about reporting a cut+paste-able error string that the admin's can use to test why the query failed. Having to hand-edit out the '?' and then properly quote them by hand is rather error prone. What I need is something that will replace the original input string '?' characters with properly [un-]quoted values from the bind paramter list so that queries which begin life as: select * from foo where field = ? get turned into select * from foo where field = '500' (if 500 is being used for a stringy comparision in the SQL based on the underlying field types). The problem is that admin's who are trying to deal with a problem at 3am are in no mood to stumble around finding field types so that they can put quotes around things when they cut+paste my bind values to generate a valid query string that they can use in the client shell to test why the database spat out a particular error. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 888 359 3508
RE: Query formatting problem
Ah yes, I've often wanted also to be able to dump the SQL string but have not seen any such method. I took a look at the source of my copies of DBI.pm and DBD.pm to see if it's an undocumented feature but didn't find any thing like that. Perhaps Tim will add this functionality, a companion method to $sth-dump_results called $sth-dump_query? -Original Message- From: Steven Lembark [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 2:40 PM To: Fong, Anna Subject: RE: Query formatting problem -- Fong, Anna [EMAIL PROTECTED] I'm not sure of the source of your assigned variables ($a, $today) and maybe I don't understand what you're trying to do but wouldn't you want to make sure the values are valid before even getting to the query? At that point you can have the script throw an error if the datatype is not right. Unless you don't know the datatypes in your tables, in which case you'll need to better coordinate with your DBA. The issue is not validating values, it is reproducing errors in the database shell. Say I run: my $rowz = selectall_arrayref( $sql, undef, @valuz ); and it blows up. The admin's get a message in the file. If my query looked like: select * from foboar where field1 = ? and field2 ?; then they cannot simply cut+paste the sql in order to reproduce the problem and test why the job failed. This has NOTHING to do with running queries, only reporting errors that show the placeholders interpolated. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 888 359 3508
Re: ActiveState Awards
Remember, vote early and vote often. We'll have to work on ActiveState as to why Tim's at the bottom of the ballot. He should be first (alphabetically!) ;-) BTW: http://www.activestate.com/Corporate/ActiveAwards On Jun 12, [EMAIL PROTECTED] scribed: ...Has anybody mentioned that Tim is a nominee??? I just voted for him, nudge nudge, wink wink, say no more, say no more. -- E-Mail: [EMAIL PROTECTED] Date: 12-Jun-2003 Time: 13:20:34 --
Re: Announce: DBD::Pg 1.30_2 (beta)
Rudy Lippan wrote: DBD::Pg 1.30 is nearing release, and you can grab a copy of the latest beta at: http://www.remotelinux.com/rlippan/DBD-Pg-1.30_2.tar.gz Hi Rudy, here is the result of my tests, with either DBI 1.35 and 1.37 and Postgresql version 7.3.3. I'm having several problems with the test scripts. I cannot understand if these are caused by my setup... OS: Linux RedHat 7.3 Pg: 7.3.3 Perl : 5.6.1 DBI : 1.35 and 1.37 DBD-PG: 1.30_2 First I was using DBD::Pg 1.22 with DBI 1.30 through 1.37 with no problems. I upgraded from Postgresql 7.1.3 to 7.3.3 because 7.2 was a prerequisite. Here I include output of `make test' with DBI 1.37. Hope that this can be of any help. Output of testing with DBI 1.35 is very similar but the number of failed subtests is 80 instead of 92. Please tell if I can test and/or report something more to help. Output of `make test' --- [EMAIL PROTECTED]://~/files/DBD-Pg-1.30_2 14:36:03$DBI_DSN=dbi:Pg:dbname=pg130test DBI_USER=postgres make test /bin/sh -c true /bin/sh -c true PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/opt/perl/lib/5.6.1/linux -I/opt/perl/lib/5.6.1 -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/00basic...ok t/01connect.ok t/01constants...ok t/01setup...ok t/02prepare.ok t/03binddubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 5-11 Failed 7/11 tests, 36.36% okay t/04execute.dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 5-13 Failed 9/13 tests, 30.77% okay t/05fetch...dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 9-10 Failed 2/10 tests, 80.00% okay (less 3 skipped tests: 5 okay, 50.00%) t/06disconnect..ok t/07reuse...ok t/08txn.ok t/09autocommit..ok t/11quoting.dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 2-9 Failed 8/9 tests, 11.11% okay t/12placeholdersdubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 5-9 Failed 5/9 tests, 44.44% okay t/13pgtype..ok t/15funct...dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 11-71 Failed 61/71 tests, 14.08% okay t/99cleanup.ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/03bind.t011117 63.64% 5-11 t/04execute.t 011139 69.23% 5-13 t/05fetch.t 011102 20.00% 9-10 t/11quoting.t 011 98 88.89% 2-9 t/12placeholders.t011 95 55.56% 5-9 t/15funct.t 01171 61 85.92% 11-71 3 subtests skipped. Failed 6/17 test scripts, 64.71% okay. 92/201 subtests failed, 54.23% okay. make: *** [test_dynamic] Error 11 [EMAIL PROTECTED]://~/files/DBD-Pg-1.30_2 14:36:30$ -- Cosimo
Re: Announce: DBD::Pg 1.30_2 (beta)
On Thu, 12 Jun 2003, Cosimo Streppone wrote: Date: Thu, 12 Jun 2003 14:59:30 + Hi Rudy, Hi Cosimo, First off, Thank you! here is the result of my tests, with either DBI 1.35 and 1.37 and Postgresql version 7.3.3. I'm having several problems with the test scripts. That is good! In a good-that-we-caught-it sort of way :) I cannot understand if these are caused by my setup... Yes and no. How about we say that your setup exposes a bug in DBD::Pg. OS: Linux RedHat 7.3 Pg: 7.3.3 Perl : 5.6.1 Is this the perl that came with 5.6.1? If so, I'll set up a RH 7.3 system to see if I can duplicated the problem. If you are not using the default perl, can you send me the output of 'perl -V' Please tell if I can test and/or report something more to help. See above. Output of `make test' --- [EMAIL PROTECTED]://~/files/DBD-Pg-1.30_2 14:36:03$DBI_DSN=dbi:Pg:dbname=pg130test DBI_USER=postgres make test /bin/sh -c true /bin/sh -c true PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/opt/perl/lib/5.6.1/linux -I/opt/perl/lib/5.6.1 -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/00basic...ok t/01connect.ok t/01constants...ok t/01setup...ok t/02prepare.ok t/03binddubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 5-11 Hum, Looks like there is a problem in bind(). David reported something, and I am noticing some weirdness there but only when perl is compiled with -O6. The rest of the test are binding values to placeholders which would explain why they are failing. Rudy
Re: Announce: DBD::Pg 1.30_2 (beta)
Rudy Lippan wrote: here is the result of my tests, with either DBI 1.35 and 1.37 and Postgresql version 7.3.3. I'm having several problems with the test scripts. That is good! In a good-that-we-caught-it sort of way :) Sure! OS Linux RedHat 7.3, Pg 7.3.3, Perl 5.6.1 Is this the perl that came with 5.6.1? If so, I'll set up a RH 7.3 system to see if I can duplicated the problem. I'm not using the default RH perl. I'm including here the full `perl -V`. Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.18-3, archname=linux uname='linux satcli03 2.4.18-3 #1 thu apr 18 07:37:53 edt 2002 i686 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-ffast-math -fno-strict-aliasing -I/usr/local/include -mpentiumpro -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-ffast-math -fno-strict-aliasing -I/usr/local/include -mpentiumpro' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.3 2.96-110)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=define, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Jun 28 2002 18:35:40 @INC: /opt/perl/lib/5.6.1/linux /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/linux /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl . -- Cosimo Choose two: (A) Fast (B) Efficient (C) Stable (D) Windows 98 (counts as two)
Re: Announce: DBD::Pg 1.30_2 (beta)
I'm seeing some errors appearing in my Apache log under Bricolage. Not sure what the deal is, but this didn't happen under DBD::Pg 1.22 or earlier: WARNING: BEGIN: already a transaction in progress WARNING: COMMIT: no transaction in progress WARNING: BEGIN: already a transaction in progress WARNING: COMMIT: no transaction in progress Issuing rollback() for database handle being DESTROY'd without explicit disconnect() at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 1661. rollback ineffective with AutoCommit enabled at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 960. [Thu Jun 12 11:42:09 2003] [error] [client 127.0.0.1] Unable to commit transactions: DBD::Pg::db commit failed: begin failed at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 571. It seems rather confused about transaction states...In Bricolage, each Apache request is a single transaction. Rudy, do you know offhand what might be causing this? Regards, David
