Reconnecting to a database
Hi list, I have a long running script that needs to be able to reconnect to the database (mysql) since the db is restarted sometimes. My plan was to subclass DBI (like in the t/ dir) and add checks in execute and the fetch methods of MyDBI::st, and if the DB has gone away reconnect and re-run the prepare and then execute. I've reached the point where I do execute and see that the DB is gone. My problem is that at that point (in the MyDBI::st::execute) is all I have a reference to myself, not to the dbh used to do the prepare so what I wonder is how should I go about changing the handle? What I've don is basicly: package MyDBI; use strict; use DBI; use DBD::mysql; use vars qw(@ISA); @ISA = qw(DBI); sub connect { my $self = shift; my ($dsn, $uname, $passwd) = @_; my $this = $class-SUPER::connect($dsn, $uname, $passwd); $this-set_dsn ($dsn, $uname, $passwd); # so I can reconnect easily return $this; } package MyDBI::db; @MyDBI::db::ISA = qw(DBI::db); my ($_uname, $_passwd, $_dsn); sub set_dsn { my $this = shift; ($_dsn, $_uname, $_passwd) = @_; } sub reconnect { # somthing like MyDBI-connect ($_dsn, $_uname, $_passwd); # and then rerun prepare } package MyDBI::st; @MyDBI::st::ISA = qw(DBI::st); sub execute { my $this = shift; $this-SUPER::execute (@_); if ($this-errstr =~ /server has gone away/) { MyDBI::db-reconnect; # and then rerun execute with some sleep to avoid insane bahviour } } 1; So basicly, my problem is that my script calling here has a dbh and i need that to be changed... Thanks /jon
Insert/Update performance issues with Oracle 10gR2 + DBI + DBD::Oracle
We're upgrading from 8i to 10g (using materialized views and more). We're having strange issues with simple inserts and updates. Here's what we observed: For the foll. query UPDATE job_descr SET phase_id = 2 WHERE jobid = 11576242 1. Runs in a fraction of a second from Toad 2. Runs in a fraction of a second from sqlplus 3. Takes 5 seconds(!) using Oracle 10gR2, DBI 1.53, DBD::Oracle 1.18 The code is essentially as follows: my $sql = SELECT ...; my $sth = $dbh-prepare( $sql ) || die Preparing $sql\n; $sth-execute || die Died: $sql\n; A DBI Trace around the $sth-execute where the 5s is spent shows the foll: DBI 1.53-nothread default trace level set to 0x0/10 (pid 24811) prepare DISPATCH (DBI::db=HASH(0x9ca599c) rc1/2 @2 g0 ima2201 pid#24811) at test.pl line 30 via at test.pl line 20 - prepare for DBD::Oracle::db (DBI::db=HASH(0x9ca599c)~0x9ca84cc 'UPDATE job_descr SET phase_id = 2, status_id = 10039 WHERE jobid = 11576242') New DBI::st (for DBD::Oracle::st, parent=DBI::db=HASH(0x9ca84cc), id=) dbih_setup_handle(DBI::st=HASH(0x9ca85f8)=DBI::st=HASH(0x9ca8a10), DBD::Oracle::st, 9ca8604, Null!) dbih_make_com(DBI::db=HASH(0x9ca84cc), 9ca8790, DBD::Oracle::st, 216, 0) thr#0 dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), Err, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf0f4) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), State, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf154) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), Errstr, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf124) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), TraceLevel, DBI::db=HASH(0x9ca84cc)) 0 (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), FetchHashKeyName, DBI::db=HASH(0x9ca84cc)) 'NAME' (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), HandleSetErr, DBI::db=HASH(0x9ca84cc)) undef (not defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), HandleError, DBI::db=HASH(0x9ca84cc)) undef (not defined) OCIHandleAlloc(9cc5208,9d05d80,OCI_HTYPE_STMT,0,0)=SUCCESS OCIStmtPrepare(9ce426c,9cdbf90,'UPDATE job_descr SET phase_id = 2, status_id = 10039 WHERE jobid = 11576242',91,1,0)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,9d05d84,0,24,9cdbf90)=SUCCESS dbd_st_prepare'd sql UPDATE (pl1, auto_lob1, check_sql1) dbd_describe skipped for UPDATE - prepare= DBI::st=HASH(0x9ca85f8) at test.pl line 30 via at test.pl line 20 Before execute execute DISPATCH (DBI::st=HASH(0x9ca85f8) rc1/1 @1 g0 ima1041 pid#24811) at test.pl line 33 via at test.pl line 20 - execute for DBD::Oracle::st (DBI::st=HASH(0x9ca85f8)~0x9ca8a10) dbd_st_execute UPDATE (out0, lob0)... HERE IS WHERE THE CONNECTION SEEMS TO BLOCK OCIStmtExecute(9cdbf1c,9ce426c,9cdbf90,1,0,0,0,32)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,bfffa7b8,0,9,9cdbf90)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,bfffa7b6,0,10,9cdbf90)=SUCCESS dbd_st_execute UPDATE returned (SUCCESS, rpc1, fn5, out0) - execute= 1 at test.pl line 33 via at test.pl line 20 After execute DESTROY DISPATCH (DBI::st=HASH(0x9ca85f8) rc1/1 @1 g0 ima4 pid#24811) at test.pl line 20 via at test.pl line 20 DESTROY(DBI::st=HASH(0x9ca85f8)) ignored for outer handle (inner DBI::st=HASH(0x9ca8a10) has ref cnt 1) DESTROY DISPATCH (DBI::st=HASH(0x9ca8a10) rc1/1 @1 g0 ima4 pid#24811) at test.pl line 20 via at test.pl line 20 - DESTROY for DBD::Oracle::st (DBI::st=HASH(0x9ca8a10)~INNER) dbd_st_destroy OCIHandleFree(9ce426c,OCI_HTYPE_STMT)=SUCCESS - DESTROY= undef at test.pl line 20 via at test.pl line 20 DESTROY (dbih_clearcom) (sth 0x9ca8a10, com 0x9d05d00, imp DBD::Oracle::st): FLAGS 0x182591: COMSET Warn RaiseError PrintError PrintWarn ShowErrorStatement LongTruncOk PARENT DBI::db=HASH(0x9ca84cc) KIDS 0 (0 Active) IMP_DATA undef LongReadLen 64000 NUM_OF_FIELDS -1 NUM_OF_PARAMS 0 dbih_clearcom 0x9ca8a10 (com 0x9d05d00, type 3) done. ELAPSED: 5.100781 Any help will be much appreciated.
DBI - error
Hi, I am trying to execute the stored procedure using dbh. The procedure details are as follows: proc_dequeue( BALID,strRequestXML,strStatus) where: BALID - Integer, strRequestXML - XMLType, strStatus - varchar The perl script implemented is : my $sth = $dbh1-prepare(begin proc_dequeue(:BALID,:strRequestXML,:strStatus); end;); $sth-bind_param_inout(:BALID,\$o_balid,20,\%attr ); $sth-bind_param_inout(:strRequestXML,\$o_requestXML,5,\%attr); $sth-bind_param_inout(:strStatus,\$o_status,2,\%attr); and the error message i am getting is : DBD::Oracle::st execute failed: ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'proc_dequeue' ORA-06550: line 1, column 7: PL/SQL: Statement ignored (DBD ERROR: OCIStmtExecute) at ./ListenerBalA line 32. DBD::Oracle::st execute failed: ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'proc_dequeue' Please help me to resolve this problem. Thanks in advance. Regards, Sumitra Tech Mahindra, formerly Mahindra-British Telecom. Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review at a href=http://www.techmahindra.com/Disclaimer.html;http://www.techmahindra.com/Disclaimer.html/a externally and a href=http://tim.techmahindra.com/Disclaimer.html;http://tim.techmahindra.com/Disclaimer.html/a internally within Tech Mahindra.
Reconnecting to a database
Hi List, Sorry if this turns out to be a double post, I mailed this question a few hours ago but haven't got it myself. I have a script that runs over a long period of time. During this time the database (mysql) might shut down for maintance/backup and I want the script to survive that. The way I want to handle it is if connection closed sleep a while, try to reconnect and then try again a few times (the server is normaly down for 2s-2minutes. That is, basicly I want it to act like mysql_auto_reconnect except I also want it to handle if the server is down when it tries to reconnect instead of giving up there. To solve this did I make a subclass of DBI and override execute/fetch* in DBI::st. Now, my problem is that I, of course, get an DBI::st object into MyDBI::st-execute and I want to basicly do: package MyDBI::st; @MyDBI::st::ISA = qw(DBI::st); sub execute { my $this = shift; if (!$this-{DataBaseHandle}-ping) { while (!$this-{DataBaseHandle}-ping)) { #reconnect last; sleep 5; } # undo old prepare to avoid possible # re-run prepare } return $this-SUPER::execute (@_); } so when i call: $sth-execute (@bind_params); will $dbh in the script scope be reconnected and the query (and further queries) will play nicely. I know I could make some (imho) ugly hack around it all but I think it'd be a lot neater doing this way, and it'd be alot easier replacing code using DBI to use my subclass... /Jon
FW: DBD::Informix $SIG{ALRM} /etc/services
-Original Message- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: 03 November 2006 22:30 On 11/3/06, Jay Hannah [EMAIL PROTECTED] wrote: Oops. I noticed my versions were behind. I upgraded DBI and DBD::Informix. I'm still getting the same behavior (14.3 seconds to time out), so I'm still curious about what might be going on. CSDK probably uses alarm itself - for connection timeouts, no less - so your attempt to use alarm at the same time is likely to cause confusion somewhere. You could probably track this with the equivalent of truss (strace on Linux?), looking for alarm system calls in the output. You'd probably be able to identify your own alarm(2) call; you might have to work harder to identify which other alarm() calls are made before you see SIGALRM fire. Oracle has a similar issue with timing out, see perldoc DBI Signal Handling and Canceling Operations and also http://search.cpan.org/~lbaxter/Sys-SigAction/dbd-oracle-timeout.POD. The recommended solution for Oracle works fine with Informix too: __START__ use Sys::SigAction qw( set_sig_handler ); $timeout = 3; eval { my $h = set_sig_handler( 'ALRM', sub { die TIMEOUT ; } ); alarm $timeout; $dbh = DBI-connect(...); alarm(0); }; alarm(0); if ( $@ ) { if ( $@ =~ m/^TIMEOUT/ ) { ... } } __END__
RE: DBI - error
Sumitra Gatade wrote: Hi, I am trying to execute the stored procedure using dbh. The procedure details are as follows: proc_dequeue( BALID,strRequestXML,strStatus) where: BALID - Integer, strRequestXML - XMLType, strStatus - varchar The perl script implemented is : my $sth = $dbh1-prepare(begin proc_dequeue(:BALID,:strRequestXML,:strStatus); end;); $sth-bind_param_inout(:BALID,\$o_balid,20,\%attr ); $sth-bind_param_inout(:strRequestXML,\$o_requestXML,5,\%attr); $sth-bind_param_inout(:strStatus,\$o_status,2,\%attr); and the error message i am getting is : DBD::Oracle::st execute failed: ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'proc_dequeue' You are passing a string to a function that expects XMLType, an opaque Oracle object type. The XMLType API provides a constructor that takes a varchar2 argument, so try changing your statement to: begin proc_dequeue(:BALID,XMLType(:strRequestXML),:strStatus); end; Regards, Philip
Problems width system exit return code
I try to install DBD::Oracle 1.18a, width Perl 5.8, DBI 1.52, AIX 5.2, Oracle 10.2. perl Makefile.PL and make are good, and communication width DB in test are good too, but I get this error in test: t/10general. # Failed test 'system exit 1 should return 256' # in t/10general.t at line 31. # got: '-1' # expected: '256' t/10general.NOK 1 # Failed test 'system exit 0 should return 0' # in t/10general.t at line 32. t/10general.NOK 2# got: '-1' # expected: '0' t/10general.ok 3/33# Looks like you failed 2 tests of 33. t/10general.dubious Test returned status 2 (wstat 512, 0x200) I build a little test and when I connect to Oracle and then execute a S/O command, allways get $? equal 1. I don't get this error when I compile with Oracle 9.2 client, I get error width Oracle 10.2 client. Thanks. Carlos SepĂșlveda Zuvic
RE: DBI - error
This is not a DBI or a perl issue. Read your error stack and resolve your Oracle issue. -- Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Sumitra Gatade [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 6:01 AM To: dbi-users@perl.org Subject: DBI - error Hi, I am trying to execute the stored procedure using dbh. The procedure details are as follows: proc_dequeue( BALID,strRequestXML,strStatus) where: BALID - Integer, strRequestXML - XMLType, strStatus - varchar The perl script implemented is : my $sth = $dbh1-prepare(begin proc_dequeue(:BALID,:strRequestXML,:strStatus); end;); $sth-bind_param_inout(:BALID,\$o_balid,20,\%attr ); $sth-bind_param_inout(:strRequestXML,\$o_requestXML,5,\%attr); $sth-bind_param_inout(:strStatus,\$o_status,2,\%attr); and the error message i am getting is : DBD::Oracle::st execute failed: ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'proc_dequeue' ORA-06550: line 1, column 7: PL/SQL: Statement ignored (DBD ERROR: OCIStmtExecute) at ./ListenerBalA line 32. DBD::Oracle::st execute failed: ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'proc_dequeue' Please help me to resolve this problem. Thanks in advance. Regards, Sumitra Tech Mahindra, formerly Mahindra-British Telecom. Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review at a href=http://www.techmahindra.com/Disclaimer.html;http://www.techmahind ra.com/Disclaimer.html/a externally and a href=http://tim.techmahindra.com/Disclaimer.html;http://tim.techmahind ra.com/Disclaimer.html/a internally within Tech Mahindra. This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
RE: Insert/Update performance issues with Oracle 10gR2 + DBI + DBD::Oracle
Have you performed a 10046 trace? What (if any) init parameters were changed prior to moving to 10g? Do you have up to date CBO stats on your tables and data dictionary? -- Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Sanjay Noronha [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 7:47 PM To: dbi-users@perl.org Subject: Insert/Update performance issues with Oracle 10gR2 + DBI + DBD::Oracle We're upgrading from 8i to 10g (using materialized views and more). We're having strange issues with simple inserts and updates. Here's what we observed: For the foll. query UPDATE job_descr SET phase_id = 2 WHERE jobid = 11576242 1. Runs in a fraction of a second from Toad 2. Runs in a fraction of a second from sqlplus 3. Takes 5 seconds(!) using Oracle 10gR2, DBI 1.53, DBD::Oracle 1.18 The code is essentially as follows: my $sql = SELECT ...; my $sth = $dbh-prepare( $sql ) || die Preparing $sql\n; $sth-execute || die Died: $sql\n; A DBI Trace around the $sth-execute where the 5s is spent shows the foll: DBI 1.53-nothread default trace level set to 0x0/10 (pid 24811) prepare DISPATCH (DBI::db=HASH(0x9ca599c) rc1/2 @2 g0 ima2201 pid#24811) at test.pl line 30 via at test.pl line 20 - prepare for DBD::Oracle::db (DBI::db=HASH(0x9ca599c)~0x9ca84cc 'UPDATE job_descr SET phase_id = 2, status_id = 10039 WHERE jobid = 11576242') New DBI::st (for DBD::Oracle::st, parent=DBI::db=HASH(0x9ca84cc), id=) dbih_setup_handle(DBI::st=HASH(0x9ca85f8)=DBI::st=HASH(0x9ca8a10), DBD::Oracle::st, 9ca8604, Null!) dbih_make_com(DBI::db=HASH(0x9ca84cc), 9ca8790, DBD::Oracle::st, 216, 0) thr#0 dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), Err, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf0f4) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), State, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf154) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), Errstr, DBI::db=HASH(0x9ca84cc)) SCALAR(0x9abf124) (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), TraceLevel, DBI::db=HASH(0x9ca84cc)) 0 (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), FetchHashKeyName, DBI::db=HASH(0x9ca84cc)) 'NAME' (already defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), HandleSetErr, DBI::db=HASH(0x9ca84cc)) undef (not defined) dbih_setup_attrib(DBI::st=HASH(0x9ca8a10), HandleError, DBI::db=HASH(0x9ca84cc)) undef (not defined) OCIHandleAlloc(9cc5208,9d05d80,OCI_HTYPE_STMT,0,0)=SUCCESS OCIStmtPrepare(9ce426c,9cdbf90,'UPDATE job_descr SET phase_id = 2, status_id = 10039 WHERE jobid = 11576242',91,1,0)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,9d05d84,0,24,9cdbf90)=SUCCESS dbd_st_prepare'd sql UPDATE (pl1, auto_lob1, check_sql1) dbd_describe skipped for UPDATE - prepare= DBI::st=HASH(0x9ca85f8) at test.pl line 30 via at test.pl line 20 Before execute execute DISPATCH (DBI::st=HASH(0x9ca85f8) rc1/1 @1 g0 ima1041 pid#24811) at test.pl line 33 via at test.pl line 20 - execute for DBD::Oracle::st (DBI::st=HASH(0x9ca85f8)~0x9ca8a10) dbd_st_execute UPDATE (out0, lob0)... HERE IS WHERE THE CONNECTION SEEMS TO BLOCK OCIStmtExecute(9cdbf1c,9ce426c,9cdbf90,1,0,0,0,32)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,bfffa7b8,0,9,9cdbf90)=SUCCESS OCIAttrGet(9ce426c,OCI_HTYPE_STMT,bfffa7b6,0,10,9cdbf90)=SUCCESS dbd_st_execute UPDATE returned (SUCCESS, rpc1, fn5, out0) - execute= 1 at test.pl line 33 via at test.pl line 20 After execute DESTROY DISPATCH (DBI::st=HASH(0x9ca85f8) rc1/1 @1 g0 ima4 pid#24811) at test.pl line 20 via at test.pl line 20 DESTROY(DBI::st=HASH(0x9ca85f8)) ignored for outer handle (inner DBI::st=HASH(0x9ca8a10) has ref cnt 1) DESTROY DISPATCH (DBI::st=HASH(0x9ca8a10) rc1/1 @1 g0 ima4 pid#24811) at test.pl line 20 via at test.pl line 20 - DESTROY for DBD::Oracle::st (DBI::st=HASH(0x9ca8a10)~INNER) dbd_st_destroy OCIHandleFree(9ce426c,OCI_HTYPE_STMT)=SUCCESS - DESTROY= undef at test.pl line 20 via at test.pl line 20 DESTROY (dbih_clearcom) (sth 0x9ca8a10, com 0x9d05d00, imp DBD::Oracle::st): FLAGS 0x182591: COMSET Warn RaiseError PrintError PrintWarn ShowErrorStatement LongTruncOk PARENT DBI::db=HASH(0x9ca84cc) KIDS 0 (0 Active) IMP_DATA undef LongReadLen 64000 NUM_OF_FIELDS -1 NUM_OF_PARAMS 0 dbih_clearcom 0x9ca8a10 (com 0x9d05d00, type 3) done. ELAPSED: 5.100781 Any help will be much appreciated. This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying,
The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll
When I try ( $dbh = DBI-connect($dbSID,$dbUser,$dbPassword) ) or die DBI-errstr; I get a pop-up stating this error The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll What I see on the command prompt is the following install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 1678) line 3 Compilation failed in require at (eval 1678) line 3. Perhaps a required shared library or dll isn't installed where expected at C:\Perl\test.pl line 43 A similar problem was reported earlier and the suggested resolution was to download the ppm's from a site that doesn't let me in (esoftmatic.com) so I'm not sure how to proceed at this point. Any help would be greatly appreciated. Perl 8.1.7 build 815 DBI 1.52 DBD-Oracle 1.17 Oracle Client 9.2.0.1 Windows 2000 5.00.2195 SP4 Thanks, Amir.
Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll
I spent a whole day trying to what caused and found out ActiveState dll had a wrong version DLL in the 5.8.7 distro This is fixed in the 5.8.8 distro at http://www.activestate.com/store/productdetail.aspx?prdGuid=81fbce82-6bd5-49bc-a915-08d58c2648ca (be sure to download 5.8.8 or later release e.g. ActivePerl-5.8.8.819-MSWin32-x86-267479.msi works) This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: Amir Sedighi [EMAIL PROTECTED] To: dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 07, 2006 1:47 PM Subject: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll When I try ( $dbh = DBI-connect($dbSID,$dbUser,$dbPassword) ) or die DBI-errstr; I get a pop-up stating this error The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll What I see on the command prompt is the following install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 1678) line 3 Compilation failed in require at (eval 1678) line 3. Perhaps a required shared library or dll isn't installed where expected at C:\Perl\test.pl line 43 A similar problem was reported earlier and the suggested resolution was to download the ppm's from a site that doesn't let me in (esoftmatic.com) so I'm not sure how to proceed at this point. Any help would be greatly appreciated. Perl 8.1.7 build 815 DBI 1.52 DBD-Oracle 1.17 Oracle Client 9.2.0.1 Windows 2000 5.00.2195 SP4 Thanks, Amir.
Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll
There's no way to resolve this issue short of upgrading the perl version itself? Amir. - Original Message From: Martin Gainty [EMAIL PROTECTED] To: Amir Sedighi [EMAIL PROTECTED]; dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 7, 2006 2:40:53 PM Subject: Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll I spent a whole day trying to what caused and found out ActiveState dll had a wrong version DLL in the 5.8.7 distro This is fixed in the 5.8.8 distro at http://www.activestate.com/store/productdetail.aspx?prdGuid=81fbce82-6bd5-49bc-a915-08d58c2648ca (be sure to download 5.8.8 or later release e.g. ActivePerl-5.8.8.819-MSWin32-x86-267479.msi works) This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: Amir Sedighi [EMAIL PROTECTED] To: dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 07, 2006 1:47 PM Subject: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll When I try ( $dbh = DBI-connect($dbSID,$dbUser,$dbPassword) ) or die DBI-errstr; I get a pop-up stating this error The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll What I see on the command prompt is the following install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 1678) line 3 Compilation failed in require at (eval 1678) line 3. Perhaps a required shared library or dll isn't installed where expected at C:\Perl\test.pl line 43 A similar problem was reported earlier and the suggested resolution was to download the ppm's from a site that doesn't let me in (esoftmatic.com) so I'm not sure how to proceed at this point. Any help would be greatly appreciated. Perl 8.1.7 build 815 DBI 1.52 DBD-Oracle 1.17 Oracle Client 9.2.0.1 Windows 2000 5.00.2195 SP4 Thanks, Amir.
DBD::ADO and Access IMAGE (OLE Object) fields...
Hello all, I'm trying to insert images into an Access database (they're small, and that's how the app was built, not my choice), but I'm running into errors. I'm using... Windows XP SP1 ActiveState Perl: This is perl, v5.8.3 built for MSWin32-x86-multi-thread DBI 1.43 DBD::ADO 2.91 Win32::OLE 0.1701 CGI 3.01 CGI::Carp 1.27 Text::CSV_XS 0.23 I'd appreciate any feedback, and would love to have a solution... Here's a complete stand-alone script that *should* work, but doesn't, quite... Oh, you'll need to find the graphics located at the end of the script... #!perl -w use strict; eval { use DBI; }; if ($@) { die This system does not have the DBI installed!\n; } eval { use DBD::ADO; }; if ($@) { die Database type ADO not supported!\n; } eval { use CGI; }; if ($@) { die CGI module not supported!\n; } eval { use CGI::Carp; }; if ($@) { die CGI::Carp module not supported!\n; } my ($dbh, $Access, $AccessDB, $Workspace); my $db_name = 'C:\development\web\PicsDB\myPics.mdb'; my $ConnStr = dbi:ADO:Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=5;Data Source=. $db_name; my $q = new CGI; my $load = $q-param('load'); my $showPic = $q-param('showPic'); my $show_picID = $q-param('picID'); if ($load) { doDBLoad(); } else { connectDB(); if (($showPic) ($show_picID)) { showPic(); } else { showPicLinks(); } } $dbh-disconnect(); exit; sub showPic { my $sqlStatement = select picType, picData from myPics where picID = ?; my $sthSelect = $dbh-prepare($sqlStatement); eval {$sthSelect-execute($show_picID); }; if ($@) { carp(Select statement '$sqlStatement' failed!\nErrors: $dbh-errstr \n); exit; } my ($picType, $picData) = $sthSelect-fetchrow_array; $sthSelect-finish; print $q-header($picType); print $picData; } sub showPicLinks { print $q-header('text/html'); print $q-start_html(myPics DB Display); my $sqlStatement = select picID, picComment from myPics; my $sthSelect = $dbh-prepare($sqlStatement); eval {$sthSelect-execute; }; if ($@) { carp(Select statement '$sqlStatement' failed!\nErrors: $dbh-errstr \n); exit; } while (my ($picID, $picComment) = $sthSelect-fetchrow_array ) { print a href='myPics.pl?showPic=1picID=$picID'b$picComment:/b/abrimg src=myPics.pl?showPic=1picID=$picIDbr\n; } $sthSelect-finish; } sub connectDB { eval { $dbh = DBI-connect( $ConnStr, Admin, , {RaiseError = 0, PrintError = 0, AutoCommit = 1} ); }; if ($@) { die(Database connection [EMAIL PROTECTED]); } $dbh-{LongReadLen} = 200; $dbh-{LongTruncOk} = 0; } sub doDBLoad { no strict 'subs'; eval { use Text::CSV_XS; }; if ($@) { die Text::CSV_XS not supported...\n; } my $csv = Text::CSV_XS-new; print Creating database...\n; CreateAccessDB(); print Done!\n; connectDB(); eval { use Win32::OLE; Win32::OLE-Option(CP = Win32::OLE::CP_UTF8); }; if ($@) { die Win32::OLE maybe not supported...?\n; } my $create_statement = create table [myPics] ([picID] INT NOT NULL, [picComment] VARCHAR (50), [picType] VARCHAR (50), [picData] IMAGE , . PRIMARY KEY ([picID] ), CONSTRAINT myPic_PK UNIQUE ([picID] )); my $sth = $dbh-prepare($create_statement); eval {$sth-execute; }; if ($@) { die Create staement failed!\nErrors: $dbh-errstr \n; } my $sqlStatement = INSERT INTO myPics (picID, picComment, picType, picData) VALUES (?, ?, ?, ?); $sth = $dbh-prepare($sqlStatement); my $picList = PicList(); foreach (split(\n, $picList)) { if ($csv-parse($_)) { my ($picID, $picComment, $picType, $picImage) = $csv-fields; if (-e $picImage) { print Loading $picImage into database...; my $picData = readblobfile($picImage); $sth-bind_param(1, $picID); $sth-bind_param(2, $picComment); $sth-bind_param(3, $picType); # # Errors # 1) Database seems to load, but has extreme bloat, and images do not work... # 2) OLE exception from Microsoft JET Database Engine:\n\nParameter ?_4 has no default value. # 3) OLE exception from ADODB.Command:\n\nApplication uses a value of the wrong type for the current operation. # 4) OLE exception from ADODB.Parameter:\n\nArguments are of the wrong type, are out of acceptable range, or are in conflict with one another. # 5) OLE exception from Microsoft JET Database Engine:\n\nUnspecified error #Attemped Binding # Error code $sth-bind_param(4, $picData); # 1 #$sth-bind_param(4, $picData, DBI::SQL_GUID ); # 5 #$sth-bind_param(4, $picData, DBI::SQL_WLONGVARCHAR ); # 1 #$sth-bind_param(4, $picData, DBI::SQL_WVARCHAR ); # 1 #$sth-bind_param(4, $picData, DBI::SQL_WCHAR ); # 1 #$sth-bind_param(4, $picData, DBI::SQL_BIT );
Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll
Nevermind, I upgraded as Martin had suggested and all is good now. Thanks a lot. - Original Message From: Amir Sedighi [EMAIL PROTECTED] To: Martin Gainty [EMAIL PROTECTED]; dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 7, 2006 2:47:10 PM Subject: Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll There's no way to resolve this issue short of upgrading the perl version itself? Amir. - Original Message From: Martin Gainty [EMAIL PROTECTED] To: Amir Sedighi [EMAIL PROTECTED]; dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 7, 2006 2:40:53 PM Subject: Re: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll I spent a whole day trying to what caused and found out ActiveState dll had a wrong version DLL in the 5.8.7 distro This is fixed in the 5.8.8 distro at http://www.activestate.com/store/productdetail.aspx?prdGuid=81fbce82-6bd5-49bc-a915-08d58c2648ca (be sure to download 5.8.8 or later release e.g. ActivePerl-5.8.8.819-MSWin32-x86-267479.msi works) This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: Amir Sedighi [EMAIL PROTECTED] To: dbi-users Mailing List dbi-users@perl.org Sent: Tuesday, November 07, 2006 1:47 PM Subject: The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll When I try ( $dbh = DBI-connect($dbSID,$dbUser,$dbPassword) ) or die DBI-errstr; I get a pop-up stating this error The procedure entry point Perl_Glockhook_ptr could not be located in the dynamic link library perl58.dll What I see on the command prompt is the following install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 1678) line 3 Compilation failed in require at (eval 1678) line 3. Perhaps a required shared library or dll isn't installed where expected at C:\Perl\test.pl line 43 A similar problem was reported earlier and the suggested resolution was to download the ppm's from a site that doesn't let me in (esoftmatic.com) so I'm not sure how to proceed at this point. Any help would be greatly appreciated. Perl 8.1.7 build 815 DBI 1.52 DBD-Oracle 1.17 Oracle Client 9.2.0.1 Windows 2000 5.00.2195 SP4 Thanks, Amir.
Re: fetch or fetch hash/array ref?
On Mon, Nov 06, 2006 at 04:08:40PM -, [EMAIL PROTECTED] wrote: On 6 Nov 2006 at 15:08, Also Sprach Tim Bunce: Exactly. Also keep in mind the combined approach using bind_columns: $sth-execute; my %row; $sth-bind_columns( \( @row{ @{$sth-{NAME_lc} } } )); while ($sth-fetch) { print $row{region}: $row{sales}\n; } Ah. Thanks. Just what I'm after! But doesn't fetchrow_hashref do this, and more efficiently? No. On each call to fetchrow_hashref it has to FETCH the NAME attribute to get the keys to use for the hash. That's what makes fetchrow_hashref significantly slower than non-hash fetching. See the bottom half of page 24 in http://backpan.perl.org/authors/id/T/TI/TIMB/DBI_AdvancedTalk_200608.pdf for a (slightly obtuse) comparison of selectall_arrayref vs selectall_hashref vs prepare+execute+fetch loop. Tim.