perl.dbi.dev

perl.dbi.dev http://www.nntp.perl.org/group/perl.dbi.dev/ ... Copyright 1998-2008 perl.org Sat, 11 Oct 2008 14:55:42 +0000 ask@perl.org Re: Help sought with definition and implementation of ParamTypesattribute by Martin Evans H.Merijn Brand wrote: > On Fri, 10 Oct 2008 16:19:20 +0100, Martin Evans > <martin.evans@easysoft.com> wrote: > >> Hi, >> >> The DBI specification for ParamTypes taken from the DBI pod says the >> following for ParamTypes: >> >> Returns a reference to a hash containing the type information currently >> bound to placeholders. The keys of the hash are the ’names’ of the >> placeholders: either integers starting at 1, or, for drivers that >> support named placeholders, the actual parameter name string. The hash >> values are hashrefs of type information in the same form as that >> provided to the various bind_param() methods (See "bind_param" for the >> format and values), plus anything else that was passed as the third >> argument to bind_param(). Returns undef if not supported by the driver. >> >> I'm not sure why the values of the keys are hash references unless > > because if only the numeric values were supported, it would have been a > list, not a hash, but when placeholder names come in sight, a list > would not do > > $sth = $dbh->prepare ("select * from xx where xs between ? and ? or xc = ?"); > $sth->execute (4, 7, "0"); > > ParamValues => { 1 => 4, 2 => 7, 3 => "0" }, > ParamTypes => { 1 => 5, 2 => 5, 3 => 1 }, > > If param names are supported, that might look like > > ParamValues => { foo => 4, bar => 7, baz => "0" }, > ParamTypes => { foo => 5, bar => 5, baz => 1 }, but here the keys 1, 2, 3 or foo, bar and baz do not have hash references as values as per "the hash values are hashrefs" they have scalars as values. What I understood "the hash values are hashrefs" to mean was: ParamTypes => {1 => {something => x, somethingelse => y}, 2 => {something => x, somethingelse => y}} and I was questioning what the "something" and "somethingelse" were since I am only aware of a "type". >> multiple values are to be stored. If multiple values per key are stored >> what are they typically? I can only find one DBD which implements >> ParamTypes (DBD::Pg) and unless I am mistaken it sets the values of the > > I implemented it in DBD::Unify as of 0.75 in a bigger patch to > implement as much as possible of the DBI defenition: thanks for that pointer - I missed DBD::Unify > *** Release 0.75 - Tue 23 Sep 2008 <h.m.brand@xs4all.nl> > > - Three-level dbd_verbose and documentation > - $ENV{DBD_TRACE} sets $dbh->{dbd_verbose} on/before connect > - New tests for $h->trace (...) and $h->{dbd_verbose} > - Added type_info_all (), get_info (), and parse_trace_flag () > - Note that identifiers are now quoted > - Override quote_identifier () (UNIFY has no CATALOGS) > - Accept 2-arg and 3-arg ->do () > - Accept %attr to ->prepare () > - Raised all verbose levels by 1. 1 and 2 are now DBI only > - Removed 05-reauth.t > - NULLABLE now always 2, as it doesn't work > - Implemented CursorName sth attribute > - Implemented ParamValues sth attribute > - Implemented ParamTypes sth attribute > - Implemented RowsInCache sth attribute (always 0) > - Tested with Unify 6.3AB on HP-UX 10.20 with perl 5.8.8 > - Tested with Unify 8.2BC on HP-UX 11.00 with perl 5.8.8 > - Tested with Unify 8.3I on HP-UX 11.23 with perl 5.10.0 > - Tested with Unify 8.3K on AIX 5.2.0.0 with perl 5.8.8 > Tests will fail on older perls, as the test cases use scalarIO > >> keys to a scalar value - the type of the parameter. > > in dbd_st_FETCH_aatrib () > > if (kl == 10 && strEQ (key, "ParamTypes")) { > HV *hv = newHV (); > retsv = newRV (sv_2mortal ((SV *)hv)); > while (--p >= 0) { > char key[8]; > sprintf (key, "%d", p + 1); > hv_store (hv, key, strlen (key), newSViv (imp_sth->prm[p].ftp), 0); > } > } So you seem to have implemented it like DBD::Pg but that does not seem to agree with how ParamTypes is documented. >> Reason I'm asking is it is on my to do list for DBD::ODBC. > > The test case in t/20-uni-basic.t now looks like > > ok ($sth = $dbh->prepare ("select * from xx where xs between ? and ? or xc = ?"), "sel prepare"); > ok ($sth->execute (4, 7, "0"), "execute"); > ok (1, "-- Check the internals"); > { my %attr = ( # $sth attributes as documented in DBI-1.607 > NAME => [qw( xs xl xc xf xr xa xh xT xd xe )], > NAME_lc => [qw( xs xl xc xf xr xa xh xt xd xe )], > NAME_uc => [qw( XS XL XC XF XR XA XH XT XD XE )], > NAME_hash => {qw( xs 0 xl 1 xc 2 xf 3 xr 4 xa 5 xh 6 xT 7 xd 8 xe 9 )}, > NAME_lc_hash => {qw( xs 0 xl 1 xc 2 xf 3 xr 4 xa 5 xh 6 xt 7 xd 8 xe 9 )}, > NAME_uc_hash => {qw( XS 0 XL 1 XC 2 XF 3 XR 4 XA 5 XH 6 XT 7 XD 8 XE 9 )}, > uni_types => [ 5, 2, 1, 8, 7, -4, -6, -7, -3, -11], > TYPE => [ 5, 2, 1, 8, 7, 6, 7, 10, 9, 11], > PRECISION => [ 4, 9, 5, 64, 32, 9, 15, 0, 0, 0], > SCALE => [ 0, 0, 0, 0, 0, 2, 2, 0, 0, 0], > # NULLABLE => [ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1], # Does not work in Unify (yet) > NULLABLE => [ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], > CursorName => "c_sql_00_000001", > NUM_OF_FIELDS => 10, > NUM_OF_PARAMS => 3, > Database => $dbh, > ParamValues => { 1 => 4, 2 => 7, 3 => "0" }, > ParamTypes => { 1 => 5, 2 => 5, 3 => 1 }, > ParamArrays => undef, # NYI > RowsInCache => 0, > ); > foreach my $attr (sort keys %attr) { > #printf STDERR "\n%-20s %s\n", $attr, "@{$sth->{$attr}}"; > my $av = exists $sth->{$attr} ? $sth->{$attr} : undef; > is_deeply ($av, $attr{$attr}, "attr $attr"); > } > } > > Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com http://www.nntp.perl.org/group/perl.dbi.dev/2008/10/msg5502.html Fri, 10 Oct 2008 09:06:03 +0000 Re: Help sought with definition and implementation of ParamTypesattribute by H.Merijn Brand On Fri, 10 Oct 2008 16:19:20 +0100, Martin Evans <martin.evans@easysoft.com> wrote: > Hi, > > The DBI specification for ParamTypes taken from the DBI pod says the > following for ParamTypes: > > Returns a reference to a hash containing the type information currently > bound to placeholders. The keys of the hash are the ’names’ of the > placeholders: either integers starting at 1, or, for drivers that > support named placeholders, the actual parameter name string. The hash > values are hashrefs of type information in the same form as that > provided to the various bind_param() methods (See "bind_param" for the > format and values), plus anything else that was passed as the third > argument to bind_param(). Returns undef if not supported by the driver. > > I'm not sure why the values of the keys are hash references unless because if only the numeric values were supported, it would have been a list, not a hash, but when placeholder names come in sight, a list would not do $sth = $dbh->prepare ("select * from xx where xs between ? and ? or xc = ?"); $sth->execute (4, 7, "0"); ParamValues => { 1 => 4, 2 => 7, 3 => "0" }, ParamTypes => { 1 => 5, 2 => 5, 3 => 1 }, If param names are supported, that might look like ParamValues => { foo => 4, bar => 7, baz => "0" }, ParamTypes => { foo => 5, bar => 5, baz => 1 }, > multiple values are to be stored. If multiple values per key are stored > what are they typically? I can only find one DBD which implements > ParamTypes (DBD::Pg) and unless I am mistaken it sets the values of the I implemented it in DBD::Unify as of 0.75 in a bigger patch to implement as much as possible of the DBI defenition: *** Release 0.75 - Tue 23 Sep 2008 <h.m.brand@xs4all.nl> - Three-level dbd_verbose and documentation - $ENV{DBD_TRACE} sets $dbh->{dbd_verbose} on/before connect - New tests for $h->trace (...) and $h->{dbd_verbose} - Added type_info_all (), get_info (), and parse_trace_flag () - Note that identifiers are now quoted - Override quote_identifier () (UNIFY has no CATALOGS) - Accept 2-arg and 3-arg ->do () - Accept %attr to ->prepare () - Raised all verbose levels by 1. 1 and 2 are now DBI only - Removed 05-reauth.t - NULLABLE now always 2, as it doesn't work - Implemented CursorName sth attribute - Implemented ParamValues sth attribute - Implemented ParamTypes sth attribute - Implemented RowsInCache sth attribute (always 0) - Tested with Unify 6.3AB on HP-UX 10.20 with perl 5.8.8 - Tested with Unify 8.2BC on HP-UX 11.00 with perl 5.8.8 - Tested with Unify 8.3I on HP-UX 11.23 with perl 5.10.0 - Tested with Unify 8.3K on AIX 5.2.0.0 with perl 5.8.8 Tests will fail on older perls, as the test cases use scalarIO > keys to a scalar value - the type of the parameter. in dbd_st_FETCH_aatrib () if (kl == 10 && strEQ (key, "ParamTypes")) { HV *hv = newHV (); retsv = newRV (sv_2mortal ((SV *)hv)); while (--p >= 0) { char key[8]; sprintf (key, "%d", p + 1); hv_store (hv, key, strlen (key), newSViv (imp_sth->prm[p].ftp), 0); } } > Reason I'm asking is it is on my to do list for DBD::ODBC. The test case in t/20-uni-basic.t now looks like ok ($sth = $dbh->prepare ("select * from xx where xs between ? and ? or xc = ?"), "sel prepare"); ok ($sth->execute (4, 7, "0"), "execute"); ok (1, "-- Check the internals"); { my %attr = ( # $sth attributes as documented in DBI-1.607 NAME => [qw( xs xl xc xf xr xa xh xT xd xe )], NAME_lc => [qw( xs xl xc xf xr xa xh xt xd xe )], NAME_uc => [qw( XS XL XC XF XR XA XH XT XD XE )], NAME_hash => {qw( xs 0 xl 1 xc 2 xf 3 xr 4 xa 5 xh 6 xT 7 xd 8 xe 9 )}, NAME_lc_hash => {qw( xs 0 xl 1 xc 2 xf 3 xr 4 xa 5 xh 6 xt 7 xd 8 xe 9 )}, NAME_uc_hash => {qw( XS 0 XL 1 XC 2 XF 3 XR 4 XA 5 XH 6 XT 7 XD 8 XE 9 )}, uni_types => [ 5, 2, 1, 8, 7, -4, -6, -7, -3, -11], TYPE => [ 5, 2, 1, 8, 7, 6, 7, 10, 9, 11], PRECISION => [ 4, 9, 5, 64, 32, 9, 15, 0, 0, 0], SCALE => [ 0, 0, 0, 0, 0, 2, 2, 0, 0, 0], # NULLABLE => [ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1], # Does not work in Unify (yet) NULLABLE => [ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], CursorName => "c_sql_00_000001", NUM_OF_FIELDS => 10, NUM_OF_PARAMS => 3, Database => $dbh, ParamValues => { 1 => 4, 2 => 7, 3 => "0" }, ParamTypes => { 1 => 5, 2 => 5, 3 => 1 }, ParamArrays => undef, # NYI RowsInCache => 0, ); foreach my $attr (sort keys %attr) { #printf STDERR "\n%-20s %s\n", $attr, "@{$sth->{$attr}}"; my $av = exists $sth->{$attr} ? $sth->{$attr} : undef; is_deeply ($av, $attr{$attr}, "attr $attr"); } } -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/10/msg5501.html Fri, 10 Oct 2008 08:49:37 +0000 Help sought with definition and implementation of ParamTypes attribute by Martin Evans Hi, The DBI specification for ParamTypes taken from the DBI pod says the following for ParamTypes: Returns a reference to a hash containing the type information currently bound to placeholders. The keys of the hash are the ’names’ of the placeholders: either integers starting at 1, or, for drivers that support named placeholders, the actual parameter name string. The hash values are hashrefs of type information in the same form as that provided to the various bind_param() methods (See "bind_param" for the format and values), plus anything else that was passed as the third argument to bind_param(). Returns undef if not supported by the driver. I'm not sure why the values of the keys are hash references unless multiple values are to be stored. If multiple values per key are stored what are they typically? I can only find one DBD which implements ParamTypes (DBD::Pg) and unless I am mistaken it sets the values of the keys to a scalar value - the type of the parameter. Reason I'm asking is it is on my to do list for DBD::ODBC. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com http://www.nntp.perl.org/group/perl.dbi.dev/2008/10/msg5500.html Fri, 10 Oct 2008 08:20:17 +0000 RE: Bug in DBD::Oracle handling LOB columns and synonyms? by mirko.kraft Hi John, the issue pops up again and I see there is a new Bug Id #38267 for the same issue. Since I saw no reply to that last bug entry, I browsed through 1.22 oci8.c code and found the following snippet in function init_lob_refetch: ... OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, &syn_schema, &syn_schema_len, OCI_ATTR_SCHEMA_NAME, errhp, status); OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, &syn_name, &syn_name_len, OCI_ATTR_OBJ_NAME, errhp, status); ... strcpy(new_tablename,syn_schema); ... Second OCIAttrGet is obsolete. OCI_ATTR_OBJ_NAME is not defined for synonym description and should be removed. The strcpy will fail to produce correct results under certain circumstances, because for OCI_ATTR_SCHEMA_NAME Oracle doesn't guarantee a '\0' terminated string (see http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10779/oci06des. htm#446652). So this should actually be strncpy(new_tablename,syn_schema,syn_schema_len); And I still have a problem with char new_tablename[100]; being defined in the if-block, because the memory is referenced outside, and due to current implementation may be overwritten. I still think this chunk of memory has to be allocated on function block level. Just my 0.02$ ;-) Having made all this changes, I'm now no longer experiencing any problems with any kind of LOBs. Thanks for looking into this, Mirko -----Original Message----- From: Kraft, Mirko Sent: Mittwoch, 21. Mai 2008 12:26 To: 'scoles@pythian.com' Cc: dbi-dev@perl.org; 'bug-DBD-Oracle@rt.cpan.org' Subject: RE: Bug in DBD::Oracle handling LOB columns and synonyms? Hi John, the Web interface doesn't work for me, so I cc this to bug-DBD-Oracle [at] rt.cpan.org which should also be ok. I attached a diff -c on oci8.c from 1.21 which I think fixes the issue (not tested currently, however): *** oci8.c.ori Wed May 21 12:09:48 2008 --- oci8.c Wed May 21 12:16:08 2008 *************** *** 2811,2816 **** --- 2811,2819 ---- lob_refetch_t *lr = NULL; STRLEN tablename_len; char *tablename; + #ifdef OCI_ATTR_OBJ_NAME /* not in 8.0.x */ + char new_tablename[100]; + #endif /* OCI_ATTR_OBJ_NAME */ switch (imp_sth->stmt_type) { case OCI_STMT_UPDATE: *************** *** 2834,2850 **** OCIDescribeAny_log_stat(imp_sth->svchp, errhp, tablename, strlen(tablename), (ub1)OCI_OTYPE_NAME, (ub1)1, (ub1)OCI_PTYPE_SYN, dschp, status); if (status == OCI_SUCCESS) { /* There is a synonym, get the schema */ - char new_tablename[100]; char *syn_schema=NULL, *syn_name=NULL; OCIAttrGet_log_stat(dschp, OCI_HTYPE_DESCRIBE, &parmhp, 0, OCI_ATTR_PARAM, errhp, status); OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, ! &syn_schema, 0, OCI_ATTR_SCHEMA_NAME, errhp, status); OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, ! &syn_name, 0, OCI_ATTR_OBJ_NAME, errhp, status); ! strcpy(new_tablename, syn_schema); ! strcat(new_tablename, "."); ! strcat(new_tablename, syn_name); tablename=new_tablename; if (DBIS->debug >= 3) PerlIO_printf(DBILOGFP, " lob refetch synonym, schema=%s, name=%s, new tablename=%s\n", syn_schema, syn_name, tablename); --- 2837,2853 ---- OCIDescribeAny_log_stat(imp_sth->svchp, errhp, tablename, strlen(tablename), (ub1)OCI_OTYPE_NAME, (ub1)1, (ub1)OCI_PTYPE_SYN, dschp, status); if (status == OCI_SUCCESS) { /* There is a synonym, get the schema */ char *syn_schema=NULL, *syn_name=NULL; + ub4 syn_schema_len = 0, syn_name_len = 0; OCIAttrGet_log_stat(dschp, OCI_HTYPE_DESCRIBE, &parmhp, 0, OCI_ATTR_PARAM, errhp, status); OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, ! &syn_schema, &syn_schema_len, OCI_ATTR_SCHEMA_NAME, errhp, status); OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, ! &syn_name, &syn_name_len, OCI_ATTR_OBJ_NAME, errhp, status); ! strncpy(new_tablename, syn_schema, syn_schema_len); ! strcat (new_tablename, "."); ! strncat(new_tablename, syn_name, syn_name_len); tablename=new_tablename; if (DBIS->debug >= 3) PerlIO_printf(DBILOGFP, " lob refetch synonym, schema=%s, name=%s, new tablename=%s\n", syn_schema, syn_name, tablename); Thanks for looking into the issue, Mirko -----Original Message----- From: scoles@pythian.com [mailto:scoles@pythian.com] Sent: Dienstag, 20. Mai 2008 23:03 To: Kraft, Mirko Cc: dbi-dev@perl.org Subject: Re: Bug in DBD::Oracle handling LOB columns and synonyms? Ok I will have a look at it and you are right the code does not look quite right. Do you think you can raise a ticket for this at http://rt.cpan.org/Public/Dist/Display.html?Status=Active&Name=DBD-Oracl e that way I can track it better. You do not happen to know what the orginal starting line number was in oci8? cheers John SColes > Hi *, > I'm using DBD::Oracle (code checked onCPAN and verified in version 1.21) > and encountered a problem (DB is Oracle 10gR2) related to LOBs and > synonyms: > > Table TTHUMBNAIL (DOCUMENT_ID NUMBER(12), THUMBNAIL BLOB NOT NULL) is > owned by user DMSSGADM. User DMSSGDP has a synonym TTHUMBNAIL on the table > and all necessary rights granted. > > When executing the following code > > $sthInsertTTHUMBNAIL = prepareStatement($dbh, > 'INSERT ' . > 'INTO tthumbnail ' . > ' (document_id, ' . > ' thumbnail) ' . > 'VALUES (document_id_seq.CURRVAL, > ' . > ' ?)'); > $sthInsertTTHUMBNAIL->bind_param(1, $thumbnail, { ora_type => ORA_BLOB }); > $sthInsertTTHUMBNAIL->execute(); > > I get the following error: > > ORA-04043: object DMSSGADMTTHUMBNAIL.TTHUMBNAIL does not exist (DBD > SUCCESS: OCIDescribeAny(view)/LOB refetch) > > Currently I tracked down the error to the following place in oci8.c, but > since I got no compiler here, I can't verify further: > > 01 #ifdef OCI_ATTR_OBJ_NAME /* not in 8.0.x */ > 02 OCIDescribeAny_log_stat(imp_sth->svchp, errhp, tablename, > strlen(tablename), > 03 (ub1)OCI_OTYPE_NAME, (ub1)1, (ub1)OCI_PTYPE_SYN, dschp, status); > 04 if (status == OCI_SUCCESS) { /* There is a synonym, get the schema > */ > 05 char new_tablename[100]; > 06 char *syn_schema=NULL, *syn_name=NULL; > 07 OCIAttrGet_log_stat(dschp, OCI_HTYPE_DESCRIBE, > 08 &parmhp, 0, OCI_ATTR_PARAM, errhp, status); > 09 OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, > 10 &syn_schema, 0, OCI_ATTR_SCHEMA_NAME, errhp, status); > 11 OCIAttrGet_log_stat(parmhp, OCI_DTYPE_PARAM, > 12 &syn_name, 0, OCI_ATTR_OBJ_NAME, errhp, status); > 13 strcpy(new_tablename, syn_schema); > 14 strcat(new_tablename, "."); > 15 strcat(new_tablename, syn_name); > 16 tablenameew_tablename; > 17 if (DBIS->debug >= 3) > 18 PerlIO_printf(DBILOGFP, " lob refetch synonym, schema=%s, > name=%s, new tablename=%s\n", syn_schema, syn_name, tablename); > 19 } > 20 #endif /* OCI_ATTR_OBJ_NAME */ > > First, lines 05 & 16 constitute a very bad situation, since the pointer > refers to a stack variable that is freed when the block is closed :-( So > this buffer should be declared outside the block, anyway... > > And from what I know about OCIAttrGet, if you retrieve a text attribute, > you have to pass a pointer to receive the length of the string, as it is > not '\0' terminated! After that you would call something like > > strncpy(new_tablename, syn_schema, syn_schema_length); > strcpy (new_tablename, "."); > strncpy(new_tablename, syn_name, syn_name_length); > > I'm looking forward to hearing from you about the issue, since I'm really > stuck on the topic. > > Sincerely, > > Mirko Kraft > > UBS AG > Global Wealth Management & Business Banking > Information Technology > eRMS - electronic Records Management Solutions > Viaduktstr. 31-35, PO Box 4473, CH-4051 Basel > Tel. +41-61-288 53 72 > Fax +41-61-288 71 91 > www.ubs.com > > Based on previous e-mail correspondence with you and/or an agreement > reached with you, UBS considers itself authorized to contact you via > unsecured e-mail. > Warning: > (a) E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, > potential manipulation of contents and/or sender's address, incorrect > recipient (misdirection), viruses etc. UBS assumes no responsibility for > any loss or damage resulting from the use of e-mails. UBS recommends in > particular that you do NOT SEND ANY SENSITIVE INFORMATION, that you do not > include details of the previous message in any reply, and that you enter > e-mail address(es) manually every time you write an e-mail. > (b) As a matter of principle, UBS does NOT accept any ORDERS, revocations > of orders or authorizations, blocking of credit cards, etc., sent by > e-mail. Should such an e-mail nevertheless be received, UBS is not obliged > to act on or respond to the e-mail. > Please notify UBS immediately if you received this e-mail by mistake or if > you do not wish to receive any further e-mail correspondence. If you have > received this e-mail by mistake, please completely delete it (and any > attachments) and do not forward it or inform any other person of its > contents. > > > http://www.nntp.perl.org/group/perl.dbi.dev/2008/10/msg5499.html Thu, 02 Oct 2008 01:33:50 +0000 Re: Volunteers sought to help with or take over Oracle::OCI by Tim Bunce On Sat, Sep 20, 2008 at 02:55:33PM -0400, Jeff Macdonald wrote: > On Mon, Jul 21, 2008 at 3:51 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: > >> On Mon, Jul 21, 2008 at 5:23 PM, John Scoles <scoles@pythian.com> wrote: > >> > >> > I suppose I could take it over as I am doing DBD::Oracle as well. > > > > Meanwhile, I'll move the code to a public repository. > > Any progress with this? Where is the public repository? I can't find my local copy any more. I'm sure the version on CPAN is complete (http://search.cpan.org/~timb/Oracle-OCI-0.06/) so feel free to host it anywhere you like (github, google code, etc). Tim. http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5498.html Mon, 22 Sep 2008 04:39:14 +0000 Re: enhancement: DBD::Oracle and OCI_ATTR_STMT_TYPE by John Scoles Well would not be hard to do as we already have char * oci_stmt_type_name(int stmt_type) { dTHX; SV *sv; switch (stmt_type) { case OCI_STMT_SELECT: return "SELECT"; case OCI_STMT_UPDATE: return "UPDATE"; case OCI_STMT_DELETE: return "DELETE"; case OCI_STMT_INSERT: return "INSERT"; case OCI_STMT_CREATE: return "CREATE"; case OCI_STMT_DROP: return "DROP"; case OCI_STMT_ALTER: return "ALTER"; case OCI_STMT_BEGIN: return "BEGIN"; case OCI_STMT_DECLARE: return "DECLARE"; } sv = sv_2mortal(newSVpv("",0)); sv_grow(sv, 50); sprintf(SvPVX(sv),"(STMT TYPE %d)", stmt_type); return SvPVX(sv); } function internally in OCI8.c, I guess I could add it to the XS and get it into Perl. just need a name for it though. dbd_stmt_type_name? or in this case ora_stmt_type_name?? Norbert Debes wrote: > Hi, > > I'm an enthusiastic user of Perl DBI and DBD::Oracle. Thanks to Tim > Bunce and all the others who help maintain it! > > I wrote a sort of SQL*Plus replacement called DBB which runs arbitrary > SQL statements and prints SELECT output with automatic column sizing > (readable instantly without any COLUMN x FORMAT), because I'm always > annoyed that SQL*Plus can't format it's output in a readable way. It > would be cool to have OCI_ATTR_STMT_TYPE available from DBD::Oracle. > Then I could provide feedback such as "ALTER Statement executed". > Currently there seems to be now way to find out what type of statement > was executed (i.e. ALTER, DELETE, INSERT). > > DBB is included with my book "Secret ORACLE" which also has an intro > to DBI and DBD::Oracle: http://www.oradbpro.com/publications.html > > Here's a quote from OCI doc: > Table 4–1 OCI_ATTR_STMT_TYPE Values and Statement Types > Attribute Value Statement Type > OCI_STMT_SELECT SELECT statement > OCI_STMT_UPDATE UPDATE statement > OCI_STMT_DELETE DELETE statement > OCI_STMT_INSERT INSERT statement > OCI_STMT_CREATE CREATE statement > OCI_STMT_DROP DROP statement > OCI_STMT_ALTER ALTER statement > OCI_STMT_BEGIN BEGIN... (PL/SQL) > OCI_STMT_DECLARE DECLARE... (PL/SQL) > -- > Kind regards > > Norbert Debes > > ORADBPRO Consulting Services <http://www.oradbpro.com> > http://www.oradbpro.com > GSM: +49 177 6895186 > Fax: +49 1212 536735037 > SMTP: norbert.debes@oradbpro.com <mailto:norbert.debes@oradbpro.com> > > > http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5497.html Mon, 22 Sep 2008 03:58:21 +0000 enhancement: DBD::Oracle and OCI_ATTR_STMT_TYPE by Norbert Debes http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5496.html Sun, 21 Sep 2008 10:21:58 +0000 Re: Volunteers sought to help with or take over Oracle::OCI by Jeff Macdonald On Mon, Jul 21, 2008 at 3:51 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: >> On Mon, Jul 21, 2008 at 5:23 PM, John Scoles <scoles@pythian.com> wrote: >> >> > I suppose I could take it over as I am doing DBD::Oracle as well. > > Meanwhile, I'll move the code to a public repository. Any progress with this? Where is the public repository? -- Jeff Macdonald Ayer, MA http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5495.html Sat, 20 Sep 2008 11:55:41 +0000 Re: DBD::File missing f_ext by H.Merijn Brand On Thu, 18 Sep 2008 10:59:52 -0700, Jeff Zucker <jeff@vpservices.com> wrote: > H.Merijn Brand wrote: > > Attached patch implements the following: > > > > f_dir => "/data/csv/foo", > > f_ext => ".csv", > > f_ext => ".csv/i", # Case ignore on extension, use given on write > > f_ext => ".csv/r", # Extension is required, ignore other files in > > f_ext => ".csv/ri", # f_dir. Options can be combined > > I find that overly complicated, doesn't solve much, and could be done > easily with a single loop statement in Perl. The case stuff I would The reason I did the /r is that in my case I actually had "aard" and "aard.csv" and only the latter contained database data I implemeted /i, because it wasn't too hard to imagine people sending in zip files with AARD.CSV, and I don't want my script to care. > find particularly confusing since f_dir and file names (not table names) > will need to remain case sensitive on *nix regardless of what you do > with the sensitivity of the extension - SQL table names must remain > insensitive in all cases so this method of treating a filename as a That is a good reason to drop the /i support, and make /i default > tablename would make the entire situation quite confusing. The reason I > say it doesn't solve much is that it only really works if you have a > single CSV format (e.g. if you have files that use a semi-colon eol semi-colon eol's will be the odd-one-out > you'll need to specify them with $dbh->{csv_tables} attribute anyway. > Also it doesn't solve the issue of finding a list of tables - a fuller > patch would connect the specifiying of f_dir and f_ext with the > $dbh->tables () method. I guess my main approach is that filenames and > tablenames are two different things and that this patch obscures that Entirely my POV, which is why I use $h->{f_map} internally to map table names to file names > whereas most users will be better off by realizing that they are better > off making an explicit association between file names and table names Ahhhhrg, no. I have data directories with 400 csv files. You don't think I would like to specify all of those. f_dir=dta;f_ext=.csv really made my life very easy there > with $dbh->{csv_tables}->{file}. So, let me think about this patch, I'm > not ready to decide today. I will definitely apply your previous > patches from rt, thanks for those. \o/ The reasoning to push this is that we have customers who can easily dump their data like this, but getting their data in a database format they use themselves takes ages. Different version of Oracle or OS make life hard. And analyzing some data from CSV files for a one-shot action is much much faster that trying to recreate a complete database with those values. (OK, Postgress goes rather fast, but Oracle is a PITA) > TIM or others - what do you think? > > Also, thanks for your offer to take over DBD:CSV. I may sometime take > you up on that but am not ready yet, I'd prefer to keep it as long as I > have DBD::File, DBD::AnyData, and SQL::Statement since they are all so > intimately related. Is there a way we can be co-maintainers? Can I > give you PAUSE uploading rights so that you could directly upload > patches we both agree are good changes? > > Thanks for your improvements to the module. -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5494.html Thu, 18 Sep 2008 12:12:30 +0000 Re: DBD::File missing f_ext by Jeff Zucker H.Merijn Brand wrote: > Attached patch implements the following: > > f_dir => "/data/csv/foo", > f_ext => ".csv", > f_ext => ".csv/i", # Case ignore on extension, use given on write > f_ext => ".csv/r", # Extension is required, ignore other files in > f_ext => ".csv/ri", # f_dir. Options can be combined > > I find that overly complicated, doesn't solve much, and could be done easily with a single loop statement in Perl. The case stuff I would find particularly confusing since f_dir and file names (not table names) will need to remain case sensitive on *nix regardless of what you do with the sensitivity of the extension - SQL table names must remain insensitive in all cases so this method of treating a filename as a tablename would make the entire situation quite confusing. The reason I say it doesn't solve much is that it only really works if you have a single CSV format (e.g. if you have files that use a semi-colon eol you'll need to specify them with $dbh->{csv_tables} attribute anyway. Also it doesn't solve the issue of finding a list of tables - a fuller patch would connect the specifiying of f_dir and f_ext with the $dbh->tables() method. I guess my main approach is that filenames and tablenames are two different things and that this patch obscures that whereas most users will be better off by realizing that they are better off making an explicit association between file names and table names with $dbh->{csv_tables}->{file}. So, let me think about this patch, I'm not ready to decide today. I will definitely apply your previous patches from rt, thanks for those. TIM or others - what do you think? Also, thanks for your offer to take over DBD:CSV. I may sometime take you up on that but am not ready yet, I'd prefer to keep it as long as I have DBD::File, DBD::AnyData, and SQL::Statement since they are all so intimately related. Is there a way we can be co-maintainers? Can I give you PAUSE uploading rights so that you could directly upload patches we both agree are good changes? Thanks for your improvements to the module. -- Jeff http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5493.html Thu, 18 Sep 2008 11:00:00 +0000 Re: DBD::File missing f_ext by H.Merijn Brand On Tue, 16 Sep 2008 18:48:08 +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote: > I have a big directory with a CSV dump of a directory. Updates versions of DBD/File.pm and DBD/CSV.pm will be available while I dig through their restrictions as http://www.xs4all.nl/~hmbrand/DBD::File.pm http://www.xs4all.nl/~hmbrand/DBD::CSV.pm That also contains a fix for print $sth->{TYPE}[0] // "", "\n"; print $sth->{PRECISION}[0] // 10, "\n"; -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5492.html Thu, 18 Sep 2008 09:05:41 +0000 Re: DBD::File missing f_ext by H.Merijn Brand On Tue, 16 Sep 2008 18:48:08 +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote: > Suggested implementation attached. > TODO includes tests and file creation (which I didn't write yet) Much more robust version here: http://www.xs4all.nl/~hmbrand/File.pm -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5491.html Tue, 16 Sep 2008 12:55:36 +0000 Re: DBD::File missing f_ext by H.Merijn Brand On Tue, 16 Sep 2008 18:48:08 +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote: > Attached patch implements the following: 1. Patch still has a debug statement in it 2. I've tried hard to keep the original layout, but I might have failed there -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5490.html Tue, 16 Sep 2008 10:06:10 +0000 DBD::File missing f_ext by H.Merijn Brand I have a big directory with a CSV dump of a directory. The folder has a lot of table dumps in CSV format (amongst a lot of other database related files) and all those files have a lovely recognizable extension: .csv So I found it stupid from DBD::CSV to have a table.csv file and then forcing me to select from it using "table.csv" instead of "table". Having written some perl code in the past, how hard could it be to look for "open" and "opendir" and make it use "table.csv" if it exists, and if not, fall back to the default "table". Wrong. DBD::CSV is just a subclass of DBD::File, which does not support this. Dumb dumber dumbest. I'm sure Jeff wouldn't mind me taking over DBD::CSV if that were easy to fix, but it is not, so the changes in DBD::CSV are futile compared to the changes needed in DBD::File. Attached patch implements the following: f_dir => "/data/csv/foo", f_ext => ".csv", f_ext => ".csv/i", # Case ignore on extension, use given on write f_ext => ".csv/r", # Extension is required, ignore other files in f_ext => ".csv/ri", # f_dir. Options can be combined Suggested implementation attached. TODO includes tests and file creation (which I didn't write yet) f_ext This attribute is used for setting the file extension where (CSV) files are opened. There are several possibilities. DBI:CSV:f_dir=data;f_ext=.csv In this case, DBD::File will open only "table.csv" if both "table.csv" and "table" exist in the datadir. The table will still be named "table". If your datadir has files with extensions, and you do not pass this attribute, your table is named "table.csv", which is probably not what you wanted. DBI:CSV:f_dir=data;f_ext=.csv/i Same as above, but file name matching is done case‐insensitive. DBI:CSV:f_dir=data;f_ext=.csv/r In this case the extension is required, and all filenames that do not match are ignored. DBI:CSV:f_dir=data;f_ext=.csv/ri Same as above, but file name matching is done case‐insensitive. I have tested that with DBD::CSV and $ENV{DBI_DSN} = "DBI:CSV:f_dir=dta;f_ext=.csv" -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5489.html Tue, 16 Sep 2008 09:48:20 +0000 ANNOUNCE: IBM DB2 Database Driver for Perl DBI Version 1.2 released by Open Source Application Development IBM DB2 Database Driver for Perl DBI Version 1.2 has been uploaded on CPAN. DBI is an open standard application programming interface (API) that provides database access for client applications written in Perl. DBI defines a set of functions, variables, and conventions that provide a platform-independent database interface. The DBD::DB2 driver works with DBI and a DB2 client to access databases. **New In Release - Support for Trusted Context to create Trusted Connections. - Also please see the Changelog and README for Installation Caveats. Download Link http://www.cpan.org/modules/by-category/07_Database_Interfaces/DBD/DBD-DB2-1.2.tar.gz Installation Instructions http://www-306.ibm.com/software/data/db2/perl/ Support Email Addresses * This release is supported by Open Source Application Development Team * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ by searching for module DBD-DB2 * Such bug reports can be sent by email to bug-DBD-DB2@rt.cpan.org; they also get sent to opendev@us.ibm.com, etc. Download DB2 Express-C for free, go to: http://www-01.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01&S_TACT=ACDB201 Getting started with DB2 Express-C: http://www.ibm.com/developerworks/wikis/display/DB2/FREE+Book-+Getting+Started+with+DB2+Express-C Thanks, Tarun Pasrija IBM OpenSource Application Development Team India Software Labs, Bangalore (India) http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5488.html Mon, 15 Sep 2008 18:39:03 +0000 Perl/mod_perl/DBI: To thread, or not to thread by Patrick Galbraith Hi all, I'm currently working on... of all things, a book on book about web app programming with perl/apache/mysql, and I'm trying to explain what Ubuntu packages to use for installation (and I'm sure other Linux variants same applies) Ubuntu gives you: apache2-mpm-prefork apache2-prefork-dev apache2-mpm-worker apache2-threaded-dev I've used both prefork and worker (as of late, due to concerns with forking), both of which seem to work fine. Though, the DBI documentation warns of caveats of using threaded, especially if the client is not thread safe (I always compile mysql with a thread-safe client, and DBD::mysql against that thread safe client). So... I'm trying to decide if I should explain 1. There are issues with using threads - what all are they? 2. What they should use- prefork or worker? 3. What is the consensus? 4. Is there a document available giving the pros and cons? 5. What is the official state of Perl with regards to threading? As an author, I'm thinking I don't want to give advice, only inform. Thanks for you inputs, advice, suggestions, etc. -- Satyam Eva Jayate - Truth Alone Triumphs Mundaka Upanishad http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5487.html Thu, 11 Sep 2008 18:07:18 +0000 Re: Considering an SQLite-specific CPAN Module by Tom Browder On Tue, Sep 9, 2008 at 9:15 PM, Darren Duncan <darren@darrenduncan.net> wrote: > Another distribution, DBD::SQLite::Amalgamation is a quasi-fork of > DBD::SQLite and is up to date with the almost latest SQLite sources; it also > adds a few more features over the last DBD::SQLite which hasn't seen a > release in over a year. You may want to consider submitting your changes to > include in DBD::SQLite::Amalgamation if appropriate. -- Darren Duncan Thanks, Darren. Actually, I read the DBI module docs a little more closely and I think I see that most, if not all, of things I was thinking about are there! -Tom http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5486.html Wed, 10 Sep 2008 02:46:14 +0000 Re: Considering an SQLite-specific CPAN Module by Darren Duncan Another distribution, DBD::SQLite::Amalgamation is a quasi-fork of DBD::SQLite and is up to date with the almost latest SQLite sources; it also adds a few more features over the last DBD::SQLite which hasn't seen a release in over a year. You may want to consider submitting your changes to include in DBD::SQLite::Amalgamation if appropriate. -- Darren Duncan Tom Browder wrote: > After looking at various modules for using SQLite, I've not found > exactly what I'm looking for. I want a pm that is higher level than > what I see in DBS::SQLite. > > I would like to see functions similar to what is available in > Win32::DBIODBC or Win32::ODBC: > > TableList # list of tables in the db > FieldNames > ColAttributes > > etc. > > I have cobbled together a pm for my use but it might be useful to > others and I would appreciate any opinions from this audience. > > Any comments are appreciated. > > -Tom http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5485.html Tue, 09 Sep 2008 19:16:06 +0000 Considering an SQLite-specific CPAN Module by Tom Browder After looking at various modules for using SQLite, I've not found exactly what I'm looking for. I want a pm that is higher level than what I see in DBS::SQLite. I would like to see functions similar to what is available in Win32::DBIODBC or Win32::ODBC: TableList # list of tables in the db FieldNames ColAttributes etc. I have cobbled together a pm for my use but it might be useful to others and I would appreciate any opinions from this audience. Any comments are appreciated. -Tom http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5484.html Tue, 09 Sep 2008 18:01:02 +0000 Re: (Fwd) noitify author of DBD::Oracle by John Scoles You can ignore it for now. It has nothing to do with the functionality of DBD::Oracle it is a CPAN file that I was mistakenly put into the manifest. cheers John Scoles Tim Bunce wrote: > ----- Forwarded message from Chuck Pareto <cpareto@h5.com> ----- > > Subject: noitify author of DBD::Oracle > Date: Wed, 27 Aug 2008 17:25:38 -0700 > From: Chuck Pareto <cpareto@h5.com> > Priority: normal > To: Tim.Bunce@pobox.com > X-Pobox-Antispam: broadband/ returned deny > > Hi, > > After trying to run make with Strawberry Perl on DBD::Oracle, I received a message that says please > contact author. The message is below. It says "Warning: the following files are missing in your kit: > > META.yml" > > > > > > Can you give any advice? > > > > > > > > > > > > > > cpan> make DBD::Oracle > > Database was generated on Wed, 27 Aug 2008 23:06:15 GMT > > Running make for module 'DBD::Oracle' > > Running make for P/PY/PYTHIAN/DBD-Oracle-1.22.tar.gz > > Checksum for C:\strawberry\cpan\sources\authors\id\P\PY\PYTHIAN\DBD-Oracle-1.22. > > tar.gz ok > > Scanning cache C:\strawberry\cpan\build for sizes > > ............................................................................DONE > > > > > > CPAN.pm: Going to build P/PY/PYTHIAN/DBD-Oracle-1.22.tar.gz > > > > Using DBI 1.607 (for perl 5.010000 on MSWin32-x86-multi-thread) installed in C:/ > > strawberry/perl/site/lib/auto/DBI/ > > > > Configuring DBD::Oracle for perl 5.010000 on MSWin32 (MSWin32-x86-multi-thread) > > > > Remember to actually *READ* the README file! Especially if you have any problems > > . > > > > Installing on a MSWin32, Ver#5.1 > > Using Oracle in C:/oracle/product/10.2.0/client_2 > > DEFINE _SQLPLUS_RELEASE = "1002000100" (CHAR) > > Oracle version 10.2.0.1 (10.2) > > Found oci directory > > Using OCI directory 'oci' > > > > Checking for functioning wait.ph > > > > > > System: perl5.010000 > > Compiler: gcc -s -O2 -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEX > > T -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX > > Linker: not found > > Sysliblist: > > > > Checking if your kit is complete... > > Warning: the following files are missing in your kit: > > META.yml > > Please inform the author. > > LD_RUN_PATH=C:/oracle/product/10.2.0/client_2/lib:C:/oracle/product/10.2.0/clien > > t_2/rdbms/lib > > Using DBD::Oracle 1.22. > > Using DBD::Oracle 1.22. > > Using DBI 1.607 (for perl 5.010000 on MSWin32-x86-multi-thread) installed in C:/ > > strawberry/perl/site/lib/auto/DBI/ > > Writing Makefile for DBD::Oracle > > > > *** If you have problems... > > read all the log printed above, and the README and README.help.txt files. > > (Of course, you have read README by now anyway, haven't you?) > > > > 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 > > C:\strawberry\perl\bin\perl.exe -p -e "s/~DRIVER~/Oracle/g" C:\strawberry\perl\s > > ite\lib\auto\DBI\Driver.xst > Oracle.xsi > > C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp -typemap > > C:\strawberry\perl\lib\ExtUtils\typemap -typemap typemap Oracle.xs > Oracle.xs > > c && C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv Oracle.xsc Oracle > > .c > > gcc -c -IC:\strawberry\c\include -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_ > > IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX > > -s -O2 -DVERSION=\"1.22\" -DXS_VERSION=\"1.22\" "-IC:\strawberry\perl\lib > > \CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\"10. > > 2.0.1\" Oracle.c > > In file included from Oracle.xs:1: > > Oracle.h:37:17: oci.h: No such file or directory > > Oracle.h:38:22: oratypes.h: No such file or directory > > Oracle.h:39:20: ocidfn.h: No such file or directory > > Oracle.h:40:18: orid.h: No such file or directory > > Oracle.h:41:17: ori.h: No such file or directory > > Oracle.h:51:54: DBIXS.h: No such file or directory > > In file included from Oracle.h:53, > > from Oracle.xs:1: > > > > > > -------------------------------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------------------------------- > > > > ATTENTION: DO NOT read, copy or disseminate this communication unless you are the intended addressee. > This message and any file(s) or attachment(s) transmitted with it are confidential, intended only for > the named recipient, and may contain information that is a trade secret, proprietary, protected by the > attorney work product doctrine, subject to the attorney-client privilege, or is otherwise protected > against unauthorized use or disclosure. This message and any file(s) or attachment(s) transmitted with > it are transmitted based on a reasonable expectation of privacy consistent with ABA Formal Opinion No. > 99-413. If you have received this communication in error, please e-mail the sender and notify the sender > immediately that you have received the communication in error. Thank you. > > ----- End forwarded message ----- > http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5483.html Fri, 05 Sep 2008 10:04:51 +0000 Re: ANNOUNCE: DBD::Oracle 1.22 Release Candidate 3 by H.Merijn Brand On Thu, 04 Sep 2008 11:01:17 -0400, John Scoles <scoles@pythian.com> wrote: > H.Merijn Brand wrote: > > On Wed, 30 Jul 2008 18:00:52 -0400, John Scoles <scoles@pythian.com> > > wrote: > > > >> Ok hot off the press RC3 > >> > >> A few more minor fixed but a last minute patch for ora_lob_chunk_size > >> function > >> > >> It can be found in the usual spot > >> > >> http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.22-RC3.tar > > > > <rant>What really pisses me off in Oracle 10 (beside all the normal > > Oracle hate) is the new (mis)feature of a Recyle Bin. WTF, a database > > is not a windows system!</rant> > > > > That said, I think it would be neat if DBD::Oracle would clean up the > > recycle bin after it has done it's testing. > > > <RERANT>Unfortunately this is way to far on the Oracle DBA side to be > part of DBD::Oracle, One has to do the Purge command while logged in as > a user with 'SYSTEM' privs or greater. It would also Purge ie (empty, > delete, erase kill) the entire Recycle Bin something that may tick off > you friendly neighborhood DBA. I would so much love to be able to type SQL > PURGE ORACLE CASCADING CONSTRAINTS INCLUDING HISTORY; and see it actually work. > As well this is a (mis)feature can be turned off or on so one would have > to test for that then test to see if the user has purge etc. > > Not something I think one should introduce in DBD::Oracle. I think it > would result in a loss of confidence in DBI and DBD as we would start > doing SYSTEM type work on table space right from the start. OK, a friendly warning then? (/me just typed "ALTER DATABASE FLASHBACK OFF;" and added recyclebin = OFF to the .ora startup file) > cheers > John Scoles > > >> Cheers and thanks for all the help guys -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5482.html Thu, 04 Sep 2008 08:10:17 +0000 Re: ANNOUNCE: DBD::Oracle 1.22 Release Candidate 3 by John Scoles H.Merijn Brand wrote: > On Wed, 30 Jul 2008 18:00:52 -0400, John Scoles <scoles@pythian.com> > wrote: > > >> Ok hot off the press RC3 >> >> A few more minor fixed but a last minute patch for ora_lob_chunk_size >> function >> >> It can be found in the usual spot >> >> http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.22-RC3.tar >> > > <rant>What really pisses me off in Oracle 10 (beside all the normal > Oracle hate) is the new (mis)feature of a Recyle Bin. WTF, a database > is not a windows system!</rant> > > That said, I think it would be neat if DBD::Oracle would clean up the > recycle bin after it has done it's testing. > > <RERANT>Unfortunately this is way to far on the Oracle DBA side to be part of DBD::Oracle, One has to do the Purge command while logged in as a user with 'SYSTEM' privs or greater. It would also Purge ie (empty, delete, erase kill) the entire Recycle Bin something that may tick off you friendly neighborhood DBA. As well this is a (mis)feature can be turned off or on so one would have to test for that then test to see if the user has purge etc. Not something I think one should introduce in DBD::Oracle. I think it would result in a loss of confidence in DBI and DBD as we would start doing SYSTEM type work on table space right from the start. cheers John Scoles >> Cheers and thanks for all the help guys >> > > http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5481.html Thu, 04 Sep 2008 07:58:09 +0000 Re: ANNOUNCE: DBD::Oracle 1.22 Release Candidate 3 by H.Merijn Brand On Wed, 30 Jul 2008 18:00:52 -0400, John Scoles <scoles@pythian.com> wrote: > Ok hot off the press RC3 > > A few more minor fixed but a last minute patch for ora_lob_chunk_size > function > > It can be found in the usual spot > > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.22-RC3.tar <rant>What really pisses me off in Oracle 10 (beside all the normal Oracle hate) is the new (mis)feature of a Recyle Bin. WTF, a database is not a windows system!</rant> That said, I think it would be neat if DBD::Oracle would clean up the recycle bin after it has done it's testing. > Cheers and thanks for all the help guys -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5480.html Thu, 04 Sep 2008 07:29:09 +0000 Re: Taking trace () to the next level ... by John Scoles H.Merijn Brand wrote: > On Tue, 02 Sep 2008 19:03:26 +0100, "Martin J. Evans" > <martin.evans@easysoft.com> wrote: > > >> H.Merijn Brand wrote: >> >>> On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <Tim.Bunce@pobox.com> >>> wrote: >>> >>> >>>> On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: >>>> >>>>> On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@pobox.com> >>>>> wrote: >>>>> >>>>> >>>>>> On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce >>>>>>> <Tim.Bunce@pobox.com> wrote: >>>>>>> >>>>>>> >>>>>>>> Having said all that, I can see some value in having a >>>>>>>> separate driver trace level. I suggest a few of the "middle >>>>>>>> 16 bits" are given over to >>>>>>>> >>>>>>> IMHO 4 bits will do (0..15). If that is correct, I'll also >>>>>>> change the levels to leave the basic levels 1 and 2 alone. >>>>>>> >>>>>> Actually I'd rather squeeze the levels concept down to 0..7 for >>>>>> both DBI and DBD levels in order to make two more flag bits >>>>>> available and to encourage greater use of flags. >>>>>> >>>>> FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving >>>>> 1 and 2 for DBI output only). >>>>> >>>>> Whether that matters is another issue, but 4 bits would be >>>>> preferred (though three is not the end of the world). Unless you >>>>> have a use for those 2 bits at the back of your mind... >>>>> >>>> Although it looks like the trace level range is being reduced, it's >>>> effectively being increased. It's just that instead of a single >>>> range you'd now have two. >>>> >>>> The current highest levels of driver internals tracing would then >>>> be controlled via the DBD trace level. Something like this: >>>> >>>> $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 >>>> >>>> That gives you more control because you can enable higher levels of >>>> DBD tracing without being swamped by higher levels of DBI tracing. >>>> >>>> >>>> >>>> >>> Sounds ok >>> >>> >>>> You could/should also define some trace flags for specific topics >>>> to give finer control. Something like this: >>>> >>>> $h->trace("2,-4,ix_charset"); >>>> >>> We will need some extra macro's to get the dbd level and the flags >>> Any suggestions? >>> >>> >> I like what I'm reading in this thread. As others have said I would find >> it beneficial to be able to trace DBD::ODBC without getting DBI tracing. >> In an attempt to get DBD::ODBC tracing without DBI tracing I moved some >> tracing to trace flags. Unfortunately, this had a rather unfortunate >> side effect. I created an odbcconnection trace flag and put all my >> connection tracing under that. The problem is the only way to set the >> flag before connecting :-( is: >> > > That is why I also support $ENV{DBD_TRACE}, in analogy with > $ENV{DBI_TRACE}. > > I would have to agree with $ENV{DBD_TRACE} It would be very useful for me while debugging connections as well. >> use DBD::ODBC; >> DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode'); >> >> The current trace macros allow tracing if a flag is set, tracing if a >> flag is set and the trace level is at least N, and tracing if the level >> is at least N but NOT tracing if a flag is set OR the level is at least >> N. I'd find the latter greatly beneficial for the above reason. >> > > http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5479.html Wed, 03 Sep 2008 04:05:54 +0000 Re: Taking trace () to the next level ... by H.Merijn Brand On Tue, 02 Sep 2008 19:03:26 +0100, "Martin J. Evans" <martin.evans@easysoft.com> wrote: > H.Merijn Brand wrote: > > On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <Tim.Bunce@pobox.com> > > wrote: > > > > > On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: > > >> On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@pobox.com> > > >> wrote: > > >> > > >>> On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: > > >>> > > >>> > > >>> > > >>> > > >>>> On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce > > >>>> <Tim.Bunce@pobox.com> wrote: > > >>>> > > >>>>> Having said all that, I can see some value in having a > > >>>>> separate driver trace level. I suggest a few of the "middle > > >>>>> 16 bits" are given over to > > >>>> IMHO 4 bits will do (0..15). If that is correct, I'll also > > >>>> change the levels to leave the basic levels 1 and 2 alone. > > >>> Actually I'd rather squeeze the levels concept down to 0..7 for > > >>> both DBI and DBD levels in order to make two more flag bits > > >>> available and to encourage greater use of flags. > > >> FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving > > >> 1 and 2 for DBI output only). > > >> > > >> Whether that matters is another issue, but 4 bits would be > > >> preferred (though three is not the end of the world). Unless you > > >> have a use for those 2 bits at the back of your mind... > > > Although it looks like the trace level range is being reduced, it's > > > effectively being increased. It's just that instead of a single > > > range you'd now have two. > > > > > > The current highest levels of driver internals tracing would then > > > be controlled via the DBD trace level. Something like this: > > > > > > $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 > > > > > > That gives you more control because you can enable higher levels of > > > DBD tracing without being swamped by higher levels of DBI tracing. > > > > > > > > > > > > > Sounds ok > > > > > You could/should also define some trace flags for specific topics > > > to give finer control. Something like this: > > > > > > $h->trace("2,-4,ix_charset"); > > > > We will need some extra macro's to get the dbd level and the flags > > Any suggestions? > > > > I like what I'm reading in this thread. As others have said I would find > it beneficial to be able to trace DBD::ODBC without getting DBI tracing. > In an attempt to get DBD::ODBC tracing without DBI tracing I moved some > tracing to trace flags. Unfortunately, this had a rather unfortunate > side effect. I created an odbcconnection trace flag and put all my > connection tracing under that. The problem is the only way to set the > flag before connecting :-( is: That is why I also support $ENV{DBD_TRACE}, in analogy with $ENV{DBI_TRACE}. > use DBD::ODBC; > DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode'); > > The current trace macros allow tracing if a flag is set, tracing if a > flag is set and the trace level is at least N, and tracing if the level > is at least N but NOT tracing if a flag is set OR the level is at least > N. I'd find the latter greatly beneficial for the above reason. -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5478.html Tue, 02 Sep 2008 15:13:29 +0000 Re: Taking trace () to the next level ... by Martin J. Evans H.Merijn Brand wrote: > On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <Tim.Bunce@pobox.com> > wrote: > > > On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: > >> On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@pobox.com> > >> wrote: > >> > >>> On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: > >>> > >>> > >>> > >>> > >>>> On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce > >>>> <Tim.Bunce@pobox.com> wrote: > >>>> > >>>>> Having said all that, I can see some value in having a > >>>>> separate driver trace level. I suggest a few of the "middle > >>>>> 16 bits" are given over to > >>>> IMHO 4 bits will do (0..15). If that is correct, I'll also > >>>> change the levels to leave the basic levels 1 and 2 alone. > >>> Actually I'd rather squeeze the levels concept down to 0..7 for > >>> both DBI and DBD levels in order to make two more flag bits > >>> available and to encourage greater use of flags. > >> FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving > >> 1 and 2 for DBI output only). > >> > >> Whether that matters is another issue, but 4 bits would be > >> preferred (though three is not the end of the world). Unless you > >> have a use for those 2 bits at the back of your mind... > > Although it looks like the trace level range is being reduced, it's > > effectively being increased. It's just that instead of a single > > range you'd now have two. > > > > The current highest levels of driver internals tracing would then > > be controlled via the DBD trace level. Something like this: > > > > $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 > > > > That gives you more control because you can enable higher levels of > > DBD tracing without being swamped by higher levels of DBI tracing. > > > > > > > > Sounds ok > > > You could/should also define some trace flags for specific topics > > to give finer control. Something like this: > > > > $h->trace("2,-4,ix_charset"); > > We will need some extra macro's to get the dbd level and the flags > Any suggestions? > I like what I'm reading in this thread. As others have said I would find it beneficial to be able to trace DBD::ODBC without getting DBI tracing. In an attempt to get DBD::ODBC tracing without DBI tracing I moved some tracing to trace flags. Unfortunately, this had a rather unfortunate side effect. I created an odbcconnection trace flag and put all my connection tracing under that. The problem is the only way to set the flag before connecting :-( is: use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode'); The current trace macros allow tracing if a flag is set, tracing if a flag is set and the trace level is at least N, and tracing if the level is at least N but NOT tracing if a flag is set OR the level is at least N. I'd find the latter greatly beneficial for the above reason. Martin http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5477.html Tue, 02 Sep 2008 11:03:55 +0000 Re: the return of tables () by H.Merijn Brand On Tue, 2 Sep 2008 11:01:37 +0100, Tim Bunce <Tim.Bunce@pobox.com> wrote: > > > I wasn't very clear (and was actually partly misleading). Sorry. > > > > > > What I meant was that the TABLE_CAT and/or TABLE_SCHEM columns in the > > > data returned by your table_info () method are probably empty strings but > > > should be undefs. > > > > > > What does > > > Data::Dumper::Dumper($dbh->table_info(...)->fetchall_arrayref) > > > show for an example table? > > > > $ perl -Iblib/{lib,arch} -MPROCURA::DBD -MData::Dumper > > -wle'$dbh=DBDlogon;print Dumper $dbh->table_info(undef,"PROLEP","parm")->fetchall_arrayref' $VAR1 = [ > > [ > > '', > > 'PROLEP', > > 'parm', > > 'T', > > 'W' > > ] > > ]; > > > > Correct, as that is the result of > > > > sub table_info > > { > > > my $sth = $dbh->prepare ( > > "select '', OWNR, TABLE_NAME, TABLE_TYPE, RDWRITE ". > > "from SYS.ACCESSIBLE_TABLES ". > > $where); > > > select NULL, OWNR, ... > > > > is not allowed. I don't see an easy way out > > > > sql> select NULL, OWNR, TABLE_NAME > > sql> from SYS.ACCESSIBLE_TABLES > > sql> where TABLE_NAME like 'parm'; > > NULL is not allowed in a constant list (-10518). > > Perhaps you could use some expression that happens to yield a NULL. > Or you could implement a custom quote_identifier() method. This worked: --8<--- sub quote_identifier { my ($dbh, @arg) = map { defined $_ && $_ ne "" ? $_ : undef } @_; return $dbh->SUPER::quote_identifier (@arg); } # quote_identifier -->8--- -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5476.html Tue, 02 Sep 2008 07:28:16 +0000 Re: Taking trace () to the next level ... by H.Merijn Brand On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <Tim.Bunce@pobox.com> wrote: > On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: > > On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: > > > > > On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: > > > > On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce <Tim.Bunce@pobox.com> > > > > wrote: > > > > > > > > > Having said all that, I can see some value in having a separate driver > > > > > trace level. I suggest a few of the "middle 16 bits" are given over to > > > > > > > > IMHO 4 bits will do (0..15). If that is correct, I'll also change the > > > > levels to leave the basic levels 1 and 2 alone. > > > > > > Actually I'd rather squeeze the levels concept down to 0..7 for both DBI > > > and DBD levels in order to make two more flag bits available and to > > > encourage greater use of flags. > > > > FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving 1 and 2 for > > DBI output only). > > > > Whether that matters is another issue, but 4 bits would be preferred (though > > three is not the end of the world). Unless you have a use for those 2 bits > > at the back of your mind... > > Although it looks like the trace level range is being reduced, it's > effectively being increased. It's just that instead of a single range > you'd now have two. > > The current highest levels of driver internals tracing would then > be controlled via the DBD trace level. Something like this: > > $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 > > That gives you more control because you can enable higher levels of DBD > tracing without being swamped by higher levels of DBI tracing. Sounds ok > You could/should also define some trace flags for specific topics to > give finer control. Something like this: > > $h->trace("2,-4,ix_charset"); We will need some extra macro's to get the dbd level and the flags Any suggestions? -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5475.html Tue, 02 Sep 2008 05:22:51 +0000 Re: Taking trace () to the next level ... by John Scoles Well let me weigh in here with my 2cents worth as I am back from my semi-vacation as well. First let me say that the DBD_Verbose has been a great help to me and I have at least two bug in the works were the user has used ORA_Verbose to give me an exact picture of what is going wrong with the code (OIC) which will save me a great deal of debugging time. That aside when I implemented it I simply stuck to the old KISS principle and stuck a DBD_verbse condition with each DBI_DEBUG it. Simple crude and effective. Looking at the thread the ideas seems to be 1) two ranges of debugging (DBI and DBD) 2) Flags that that can turn debugging off or on for a specific action -debug_select -debug_commit -debug_connect -debug_oracle ??? cheers John Scoles http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5474.html Tue, 02 Sep 2008 04:36:43 +0000 Re: the return of tables () by H.Merijn Brand On Tue, 2 Sep 2008 11:01:37 +0100, Tim Bunce <Tim.Bunce@pobox.com> wrote: > On Tue, Sep 02, 2008 at 12:39:41AM +0200, H.Merijn Brand wrote: > > On Mon, 1 Sep 2008 22:59:24 +0100, Tim Bunce <Tim.Bunce@pobox.com> > > wrote: > > > > > > > > > > As get_info (29) now returns a TRUE value, the 'tables ()' method is > > > > > > > > using a different strategy to build the list it returns: > > > > > > > > > > > > > > > > sub tables > > > > > > > > { > > > > > > > > my ($dbh, @args) = @_; > > > > > > > > my $sth = $dbh->table_info (@args[0..4]) or return; > > > > > > > > my $tables = $sth->fetchall_arrayref or return; > > > > > > > > my @tables; > > > > > > > > » if ($dbh->get_info (29)) { # SQL_IDENTIFIER_QUOTE_CHAR > > > > > > > > » @tables = map { $dbh->quote_identifier (@{$_}[0,1,2]) } @$tables; > > > > > > > > » } > > > > > > > > > > > Unify has no support for CATALOG's, so the values in info are not > > > > > > > > defined, but still used in the map, causing all my tables no showing up > > > > > > > > with and empty "". in front of it, which is illegal to the database :( > > > > I wasn't very clear (and was actually partly misleading). Sorry. > > > > > > What I meant was that the TABLE_CAT and/or TABLE_SCHEM columns in the > > > data returned by your table_info () method are probably empty strings but > > > should be undefs. > > > > > > What does > > > Data::Dumper::Dumper($dbh->table_info(...)->fetchall_arrayref) > > > show for an example table? > > > > $ perl -Iblib/{lib,arch} -MPROCURA::DBD -MData::Dumper > > -wle'$dbh=DBDlogon;print Dumper $dbh->table_info(undef,"PROLEP","parm")->fetchall_arrayref' $VAR1 = [ > > [ > > '', > > 'PROLEP', > > 'parm', > > 'T', > > 'W' > > ] > > ]; > > > > Correct, as that is the result of > > > > sub table_info > > { > > > my $sth = $dbh->prepare ( > > "select '', OWNR, TABLE_NAME, TABLE_TYPE, RDWRITE ". > > "from SYS.ACCESSIBLE_TABLES ". > > $where); > > > select NULL, OWNR, ... > > > > is not allowed. I don't see an easy way out > > > > sql> select NULL, OWNR, TABLE_NAME > > sql> from SYS.ACCESSIBLE_TABLES > > sql> where TABLE_NAME like 'parm'; > > NULL is not allowed in a constant list (-10518). > > Perhaps you could use some expression that happens to yield a NULL. I tried, I cannot without creating a new table, and that feels like shooting a mouse with an elefant; > Or you could implement a custom quote_identifier () method. I could, but that would feel very unsafe -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5473.html Tue, 02 Sep 2008 04:07:19 +0000 Re: Taking trace () to the next level ... by Tim Bunce On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: > On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: > > > On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: > > > On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce <Tim.Bunce@pobox.com> > > > wrote: > > > > > > > Having said all that, I can see some value in having a separate driver > > > > trace level. I suggest a few of the "middle 16 bits" are given over to > > > > > > IMHO 4 bits will do (0..15). If that is correct, I'll also change the > > > levels to leave the basic levels 1 and 2 alone. > > > > Actually I'd rather squeeze the levels concept down to 0..7 for both DBI > > and DBD levels in order to make two more flag bits available and to > > encourage greater use of flags. > > FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving 1 and 2 for > DBI output only). > > Whether that matters is another issue, but 4 bits would be preferred (though > three is not the end of the world). Unless you have a use for those 2 bits > at the back of your mind... Although it looks like the trace level range is being reduced, it's effectively being increased. It's just that instead of a single range you'd now have two. The current highest levels of driver internals tracing would then be controlled via the DBD trace level. Something like this: $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 That gives you more control because you can enable higher levels of DBD tracing without being swamped by higher levels of DBI tracing. You could/should also define some trace flags for specific topics to give finer control. Something like this: $h->trace("2,-4,ix_charset"); Tim. http://www.nntp.perl.org/group/perl.dbi.dev/2008/09/msg5472.html Tue, 02 Sep 2008 03:15:34 +0000 Re: the return of tables () by Tim Bunce On Tue, Sep 02, 2008 at 12:39:41AM +0200, H.Merijn Brand wrote: > On Mon, 1 Sep 2008 22:59:24 +0100, Tim Bunce <Tim.Bunce@pobox.com> > wrote: > > > > > > > > As get_info (29) now returns a TRUE value, the 'tables ()' method is > > > > > > > using a different strategy to build the list it returns: > > > > > > > > > > > > > > sub tables > > > > > > > { > > > > > > > my ($dbh, @args) = @_; > > > > > > > my $sth = $dbh->table_info (@args[0..4]) or return; > > > > > > > my $tables = $sth->fetchall_arrayref or return; > > > > > > > my @tables; > > > > > > > » if ($dbh->get_info (29)) { # SQL_IDENTIFIER_QUOTE_CHAR > > > > > > > » @tables = map { $dbh->quote_identifier (@{$_}[0,1,2]) } @$tables; > > > > > > > » } > > > > > > > > > Unify has no support for CATALOG's, so the values in info are not > > > > > > > defined, but still used in the map, causing all my tables no showing up > > > > > > > with and empty "". in front of it, which is illegal to the database :( > > I wasn't very clear (and was actually partly misleading). Sorry. > > > > What I meant was that the TABLE_CAT and/or TABLE_SCHEM columns in the > > data returned by your table_info () method are probably empty strings but > > should be undefs. > > > > What does > > Data::Dumper::Dumper($dbh->table_info(...)->fetchall_arrayref) > > show for an example table? > > $ perl -Iblib/{lib,arch} -MPR