RE: ANNOUNCE: DBD:Oracle 1.18
John, Found this http://e-docs.bea.com/platform/suppconfigs/configs70/hptru64unix51_alpha/70s p1.html which explains the problem of the unresolved OCILobLocatorAssign. I got our DBA to include OCILobLocatorAssign as an entrypoint in the list, rebuilt libclntsh.so, and the build works OK now. Seems like it is Oracle 8.1.7 specific, but I don't know if its just this alpha platform. There was still one error on the lob test: perl -Mblib t/31lob.t 1..9 ok 1 - returned valid locator ok 2 - returned valid locator ok 3 - returned valid locator ok 4 - returned length ok 5 - returned written value ok 6 - returned length via PL/SQL ok 7 - returned LOB as string ok 8 - returned IN/OUT LOB as string not ok 9 - no temp lobs left # Failed test (t/31lob.t at line 166) # got: '2' # expected: '0' # Looks like you failed 1 test of 9. but other than that it all looks good Thanks Michael Fox Australia Post is committed to providing our customers with excellent service. If we can assist you in any way please telephone 13 13 18 or visit our website. The information contained in this e-mail communication may be proprietary, confidential or legally professionally privileged. It is intended exclusively for the individual or entity to which it is addressed. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Australia Post does not represent, warrant or guarantee the integrity of this e-mail communication has been maintained nor that the communication is free of errors, virus or interference. If you are not the addressee or intended recipient please notify us by replying direct to the sender and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are taken to be those of the individual sender, except where the sender specifically attributes those views to Australia Post and is authorised to do so.
Re: ANNOUNCE: DBD:Oracle 1.18
On 28-Jul-2006 John Scoles wrote: > > - Original Message - > From: "Fox, Michael" <[EMAIL PROTECTED]> > To: > Sent: Thursday, July 27, 2006 11:00 PM > Subject: RE: ANNOUNCE: DBD:Oracle 1.18 > > >> >> Sorry I did not get a chance to test this before the release, but I have >> had >> a couple of problems building the new version, and any advice would be >> welcome. So far I have: >> > No problem > >> Platform: Tru64 Unix V5.1 2650 alpha, native compiler >> Oracle: 8.1.7 >> Perl: 5.8.7 >> >> Problem 1: cc: Error: Oracle.xs, line 269: In this statement, "startp" is >> not declared. (undeclared) >> ME: startp declaration has been commented out in this version, so I >> uncommented it to continue > > This is what I was afraid of. I commented it out because it was causeing my > compilers (win vc++ and lunix gcc) to throw a warning like 'startp is > declared but never used'. > Well a warning in one compiler is better than and error in an other so I > will fix that in trunk but put a comment why it is needed. Hang on. The problem is because startp is only used like this: #if !defined(ORA_OCI_8) && defined(OCI_HTYPE_DIRPATH_FN_CTX) .. .. #else OCILobGetLength_log_stat(imp_dbh->svchp, imp_dbh->errhp, locator, &startp, #endif but it is not declared conditionally. You make think warnings are better than errors but if I see a warning when I compile something it immediately makes suspicious and it is sometimes justified. Martin -- Martin J. Evans Easysoft Ltd, UK http://www.easysoft.com
Re: ANNOUNCE: DBD:Oracle 1.18
- Original Message - From: "Fox, Michael" <[EMAIL PROTECTED]> To: Sent: Thursday, July 27, 2006 11:00 PM Subject: RE: ANNOUNCE: DBD:Oracle 1.18 > > Sorry I did not get a chance to test this before the release, but I have > had > a couple of problems building the new version, and any advice would be > welcome. So far I have: > No problem > Platform: Tru64 Unix V5.1 2650 alpha, native compiler > Oracle: 8.1.7 > Perl: 5.8.7 > > Problem 1: cc: Error: Oracle.xs, line 269: In this statement, "startp" is > not declared. (undeclared) > ME: startp declaration has been commented out in this version, so I > uncommented it to continue This is what I was afraid of. I commented it out because it was causeing my compilers (win vc++ and lunix gcc) to throw a warning like 'startp is declared but never used'. Well a warning in one compiler is better than and error in an other so I will fix that in trunk but put a comment why it is needed. > > Problem 2: dbdimp.c and oci8.c look like DOS files, and the compiler > complains about carriage returns > ME: dos2unix both files to continue > Yeah found that one two. It actully crops up in a number of files. I have checked all of the files and they are all unix like now. This seems only to be a problem with older gcc compilers (or at least they detect it)? > Problem 3: unresolved > > t/01baseFailed to load Oracle extension and/or shared > libraries: > install_driver(Oracle) failed: Can't load > '/u02/devel/src/cpan_dist/modules/DBD-Oracle-1.18/blib/arch/auto/DBD/Oracle/ > Oracle.so' for module DBD::Oracle: dlopen: > /u02/devel/src/cpan_dist/modules/DBD-Oracle-1.18/blib/arch/auto/DBD/Oracle/O > racle.so: symbol "OCILobLocatorAssign" unresolved at > /usr/users/dwadmin/perl/lib/5.8.7/alpha-dec_osf/DynaLoader.pm line 230 > > ME: This is just used in dbd_rebind_ph_lob, so I replace this with the one > from DBD::Oracle version 1.17 to continue > This might be a problem more with the older oracle OCI in your client. The OCILobLocatorAssign is newer OCI code. What version of the client are you using? What I can try to do it leave this part out if the client does not support it. > Problem 4: builds OK, fails some LOB tests (not surprising given Problem > 3) > and has one warning in the array test > > perl -Mblib t/26exe_array.t > 1..13 > ok 1 - use DBI; > ok 2 - The object isa DBI::db > ok 3 - ... execute_array should return true > ok 4 - ... we should have 10 tuple_status > DBD::Oracle::st execute_array warning: ORA-24381: error(s) in array DML > (DBD > SUCCESS_WITH_INFO: error possibly near <*> indicator at char 68 in 'INSERT > INTO dbd_ora__drop_me ( row_1, row_2, row_3) VALUES (:p1,:p2<*>,:p3)') > [for > Statement "INSERT INTO dbd_ora__drop_me ( row_1, row_2, row_3) VALUES > (?,?,?)" with ParamValues: :p3=undef, :p1=undef, :p2=undef] at > t/26exe_array.t line 77. This is a deliberate waringing here. I make the sql fail to get an error report in the tuple so that in no 5 we get false (an error) and in no 7 we get the text of the error message. > ok 5 - ... execute_array should return flase > ok 6 - ... we should have 10 tuple_status > ok 7 - ... we should get text > ok 8 - ... we should get -1 > ok 9 - ... execute_for_fetch should return true > ok 10 - ... we should have 19 tuple_status > ok 11 - ... execute_array should return flase > ok 12 - ... we should have 10 tuple_status > ok 13 - ... we should have 48 rows > ""Fox, Michael"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Sorry I did not get a chance to test this before the release, but I have > had > a couple of problems building the new version, and any advice would be > welcome. So far I have: > > Platform: Tru64 Unix V5.1 2650 alpha, native compiler > Oracle: 8.1.7 > Perl: 5.8.7 > > Problem 1: cc: Error: Oracle.xs, line 269: In this statement, "startp" is > not declared. (undeclared) > ME: startp declaration has been commented out in this version, so I > uncommented it to continue > > Problem 2: dbdimp.c and oci8.c look like DOS files, and the compiler > complains about carriage returns > ME: dos2unix both files to continue > > Problem 3: unresolved > > t/01baseFailed to load Oracle extension and/or shared > libraries: > install_driver(Oracle) failed: Can't load > '/u02/devel/src/cpan_dist/modules/DBD-Oracle-1.18/blib/arch/auto/DBD/Oracle/ > Oracle.so' for module DBD::Oracle: dlopen: > /u02/devel/src/cpan_dist/modules/DBD-Oracle-1.18/blib/arch/auto/DBD/Oracle/O > racle.so: symbol "OCILobLocatorAssign" unresolved at > /usr/user
RE: ANNOUNCE: DBD:Oracle 1.18
ng DBD::Oracle for perl 5.008007 on dec_osf (alpha-dec_osf) Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /u01/app/oracle/product/8.1.7 DEFINE _SQLPLUS_RELEASE = "80107" (CHAR) Oracle version 8.1.7.0 (8.1) Found /u01/app/oracle/product/8.1.7/rdbms/demo/demo_rdbms.mk Found /u01/app/oracle/product/8.1.7/precomp/demo/proc/demo_proc.mk Using /u01/app/oracle/product/8.1.7/rdbms/demo/demo_rdbms.mk Your LD_LIBRARY_PATH env var is set to '/u01/app/oracle/product/8.1.7/lib:/usr/users/dwadmin/lib:/u02/devel/lib:/us r/users/dwadmin/samba/bin:/usr/users/dwadmin/freetds/lib:' Reading /u01/app/oracle/product/8.1.7/rdbms/demo/demo_rdbms.mk Reading /u01/app/oracle/product/8.1.7/rdbms/lib/env_rdbms.mk Attempting to discover Oracle OCI build rules cc-c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c by executing: [make -f /u01/app/oracle/product/8.1.7/rdbms/demo/demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o] Oracle oci build command: [true -L/u01/app/oracle/product/8.1.7/lib/ -L/u01/app/oracle/product/8.1.7/rdbms/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -lc] Found header files in /u01/app/oracle/product/8.1.7/rdbms/public /u01/app/oracle/product/8.1.7/rdbms/demo. Checking for functioning wait.ph System: perl5.008007 osf1 hx18.hq.auspost.com.au v5.1 2650 alpha Compiler: cc -O4 -std -D_INTRINSICS -fprm d -ieee -I/usr/local/include -DLANGUAGE_C Linker: /bin/ld Sysliblist: -lexc -lmld -lrt -laio_raw -lm Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(QACCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 -fast -fp_reorder -U_FASTMATH -O3 -fast -fp_reorder -U_FASTMATH $(GEMC_FLAGS) -std1 -DOSF1 -DA_OSF -readonly_strings -ieee -noansi_alias -D_INTRINSICS -DARCH_EV56 -arch ev56 -tune ev6 $(QACCFLAGS) -I/u01/app/oracle/product/8.1.7/rdbms/demo -I/u01/app/oracle/product/8.1.7/rdbms/public -I/u01/app/oracle/product/8.1.7/plsql/public -I/u01/app/oracle/product/8.1.7/network/public $(LPFLAGS) $(SHARED_CFLAG) $(USRFLAGS)] LDFLAGS: -L$(LIBHOME) -L$(RDBMSLIB) [-L$(LIBHOME) -L/u01/app/oracle/product/8.1.7/rdbms/lib/] Linking with OTHERLDFLAGS = -L/u01/app/oracle/product/8.1.7/lib/ -L/u01/app/oracle/product/8.1.7/rdbms/lib/ -lclntsh -lc [from 'build' rule] WARNING: If you have problems you may need to rebuild perl with threading enabled. Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. LD_RUN_PATH=/u01/app/oracle/product/8.1.7/lib:/u01/app/oracle/product/8.1.7/ rdbms/lib Using DBD::Oracle 1.18. Using DBD::Oracle 1.18. Using DBI 1.50 (for perl 5.008007 on alpha-dec_osf) installed in /usr/users/dwadmin/perl/lib/site_perl/5.8.7/alpha-dec_osf/auto/DBI/ Writing Makefile for DBD::Oracle -Original Message- From: John Scoles [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 July 2006 5:42 AM To: dbi-users@perl.org; dbi-announce@perl.org; dbi-dev@perl.org Subject: ANNOUNCE: DBD:Oracle 1.18 DBD::Oracle 1.18 has been released. With this release DBD::Oracle finally implements Oracle's native Array Interface. You will see very dramatic increase in speed. For example; the time for a 2 million plus insert query dropped from well over an hour to less than 10 minutes when using execute_array() and the new code. The new code is not 100% DBI compliant as it does not yet support named parameter binding,but it does support all the other forms of binding and has full support for return Tuples. Many thanks to Kristian Nielsen for his original work on this code. There is also expanded support for LOB Locators from Jeffrey Klein. Finally there are number of little fixes and an update or two to the readmes. please enjoy. John Scoles (Please note that it may take a little while for CPAN to update to the latest version so if you need the latest code you can always use the subversion URL http://svn.perl.org/modules/dbd-oracle/trunk.) Australia Post is committed to providing our customers with excellent service. If we can assist you in any way please telephone 13 13 18 or visit our website. The information contained in this e-mail communication may be proprietary, confidential or legally professionally privileged. It is intended exclusively for the individual or entity to which it is addressed. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Australia Post does not represent, warrant or guarantee the integrity of this e-mail communication has been maintained nor that the communication is free of errors, virus or interference. If you are not the addressee or intended recipient please notify us by replying direct to the sender and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are taken to be those of the individual sender, except where the sender specifically attributes those views to Australia Post and is authorised to do so.
Re: ANNOUNCE: DBD:Oracle 1.18
When you say named parameter binding is not supported, are you talking
about
*all* named parameters, or just for array operations?
Ohh god no!!
Just when using the execute_array(); command like this
my $sth = $dbh->prepare("INSERT INTO DETAILS ( ID, P_ID, DATE_ENTRY) VALUES
(:p1,:p2,:p3)") ;
$sth->bind_param_array(":p1",[EMAIL PROTECTED]);
$sth->bind_param_array(":p2",[EMAIL PROTECTED]);
$sth->bind_param_array(":p3",[EMAIL PROTECTED]);
$sth->execute_array();
Sorry if that casued you some trouble.
The real problem with execute_array and named parameter binding is that the
native OCI does not support it very well and I wanted to get the new version
out before I leave on summer vacation.
The plan is to add support for it with the next release some time in
October or November.
Cheers
John Scoles
- Original Message -
From: "Steve Baldwin" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 25, 2006 1:29 PM
Subject: RE: ANNOUNCE: DBD:Oracle 1.18
John,
When you say named parameter binding is not supported, are you talking
about
*all* named parameters, or just for array operations? We use named
parameters (e.g. :cust_id) extensively because it is more readable,
position
independent, and if you are using the same parameter more than once you
only
need to bind the value once. Does this mean 1.18 would break our existing
code? If so, are you expecting to rectify this behaviour - in the near
future?
Thanks,
Steve
-Original Message-
From: John Scoles [mailto:[EMAIL PROTECTED]
Sent: Monday, 24 July 2006 12:42 PM
To: dbi-users@perl.org; dbi-announce@perl.org; dbi-dev@perl.org
Subject: ANNOUNCE: DBD:Oracle 1.18
DBD::Oracle 1.18 has been released.
With this release DBD::Oracle finally implements Oracle's native Array
Interface. You will see very dramatic increase in speed.
For example; the time for a 2 million plus insert query dropped from well
over an hour to less than 10 minutes when using execute_array() and the
new
code.
The new code is not 100% DBI compliant as it does not yet support named
parameter binding,but it does support all the other forms of binding and
has
full support for return Tuples. Many thanks to Kristian Nielsen for his
original work on this code.
There is also expanded support for LOB Locators from Jeffrey Klein.
Finally there are number of little fixes and an update or two to the
readmes.
please enjoy.
John Scoles
(Please note that it may take a little while for CPAN to update to the
latest version so if you need the latest code you can always use the
subversion URL
http://svn.perl.org/modules/dbd-oracle/trunk.)
RE: ANNOUNCE: DBD:Oracle 1.18
John, When you say named parameter binding is not supported, are you talking about *all* named parameters, or just for array operations? We use named parameters (e.g. :cust_id) extensively because it is more readable, position independent, and if you are using the same parameter more than once you only need to bind the value once. Does this mean 1.18 would break our existing code? If so, are you expecting to rectify this behaviour - in the near future? Thanks, Steve > -Original Message- > From: John Scoles [mailto:[EMAIL PROTECTED] > Sent: Monday, 24 July 2006 12:42 PM > To: dbi-users@perl.org; dbi-announce@perl.org; dbi-dev@perl.org > Subject: ANNOUNCE: DBD:Oracle 1.18 > > > DBD::Oracle 1.18 has been released. > > With this release DBD::Oracle finally implements Oracle's native Array > Interface. You will see very dramatic increase in speed. > For example; the time for a 2 million plus insert query dropped from well > over an hour to less than 10 minutes when using execute_array() and the > new > code. > > The new code is not 100% DBI compliant as it does not yet support named > parameter binding,but it does support all the other forms of binding and > has > full support for return Tuples. Many thanks to Kristian Nielsen for his > original work on this code. > > There is also expanded support for LOB Locators from Jeffrey Klein. > > Finally there are number of little fixes and an update or two to the > readmes. > > please enjoy. > > John Scoles > > (Please note that it may take a little while for CPAN to update to the > latest version so if you need the latest code you can always use the > subversion URL > http://svn.perl.org/modules/dbd-oracle/trunk.) >
ANNOUNCE: DBD:Oracle 1.18
DBD::Oracle 1.18 has been released. With this release DBD::Oracle finally implements Oracle's native Array Interface. You will see very dramatic increase in speed. For example; the time for a 2 million plus insert query dropped from well over an hour to less than 10 minutes when using execute_array() and the new code. The new code is not 100% DBI compliant as it does not yet support named parameter binding,but it does support all the other forms of binding and has full support for return Tuples. Many thanks to Kristian Nielsen for his original work on this code. There is also expanded support for LOB Locators from Jeffrey Klein. Finally there are number of little fixes and an update or two to the readmes. please enjoy. John Scoles (Please note that it may take a little while for CPAN to update to the latest version so if you need the latest code you can always use the subversion URL http://svn.perl.org/modules/dbd-oracle/trunk.)
