Re: DBI - where has dbish and DBD::Shell.pm gone
H.Merijn Brand wrote: On Tue, 6 Jun 2006 14:43:49 +0200, H.Merijn Brand [EMAIL PROTECTED] wrote: On Fri, 02 Jun 2006 20:38:24 -0400, Thomas A. Lowery [EMAIL PROTECTED] wrote: Thomas A. Lowery wrote: Jeff Zucker wrote: H.Merijn Brand wrote: Can you point me to the latest version, so that I can patch against something more actual? http://svn.perl.org/modules/dbi-shell/trunk/ is sadly empty. Perhaps Tom could be persuaded to upload his most recent there. As soon as I can I've svn password reset I'll upload the current version of DBI::Shell and dbish . I've added the current release to svn.perl.org/modules/dbi-shell/trunk. What is the easiest way to get a working copy of that? # wget -m -nH -np --cut-dirs=3 http://svn.perl.org/modules/dbi-shell/trunk/ doesn't work, as it only gets index.html and robots.txt I do not have svn on my HP-UX box Well, in absence of something better, I installed it on my laptop # mkdir dbi-shell # cd dbi-shell # svn co http://svn.perl.org/modules/dbi-shell/trunk/ # mv trunk/* . # rm -rf trunk lt09:/pro/3gl/CPAN/dbi-shell 114 perl Makefile.PL Checking if your kit is complete... Looks good Warning: prerequisite IO::Tee 0 not found. Warning: prerequisite Text::Reform 0 not found. Writing Makefile for DBI::Shell lt09:/pro/3gl/CPAN/dbi-shell 115 Do we need that? IO::Tee is used by the spool command. Text::Reform is used by advance results formating. It's normal for some of the function tests to fail. lt09:/pro/3gl/CPAN/dbi-shell 116 make test PERL_DL_NONLAZY=1 /pro/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/batch...ok t/coreok t/funcNOK 7 # Failed test 'column_info tested' # in t/func.t at line 76. Use of uninitialized value in concatenation (.) or string at t/func.t line 108. Use of uninitialized value in concatenation (.) or string at t/func.t line 116. Use of uninitialized value in concatenation (.) or string at t/func.t line 127. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. Use of uninitialized value in concatenation (.) or string at t/func.t line 135. t/funcNOK 20 # Failed test 'quote_identifier( link, schema, table )' # in t/func.t at line 136. # got: 'link.schema.table' # expected: 'linkschematable' Use of uninitialized value in concatenation (.) or string at t/func.t line 162. t/funcNOK 22 # Failed test 'get_info(SQL_CATALOG_LOCATION) (114) ' # in t/func.t at line 162. Use of uninitialized value in concatenation (.) or string at t/func.t line 162. t/funcNOK 23 # Failed test 'get_info(SQL_CATALOG_NAME_SEPARATOR) (41) ' # in t/func.t at line 162.
Re: DBI - where has dbish and DBD::Shell.pm gone
Thomas A. Lowery wrote: Jeff Zucker wrote: H.Merijn Brand wrote: Can you point me to the latest version, so that I can patch against something more actual? http://svn.perl.org/modules/dbi-shell/trunk/ is sadly empty. Perhaps Tom could be persuaded to upload his most recent there. As soon as I can I've svn password reset I'll upload the current version of DBI::Shell and dbish . I've added the current release to svn.perl.org/modules/dbi-shell/trunk. Tom
Re: DBI - where has dbish and DBD::Shell.pm gone
Jeff Zucker wrote: H.Merijn Brand wrote: Can you point me to the latest version, so that I can patch against something more actual? http://svn.perl.org/modules/dbi-shell/trunk/ is sadly empty. Perhaps Tom could be persuaded to upload his most recent there. As soon as I can I've svn password reset I'll upload the current version of DBI::Shell and dbish . Regards, Tom
Re: DBD::ADO, Win32::OLE and Variant type
Steffen,
Jan will have to dig back 5-6 years for that one! IIRC, at one
point the type Variant started returning an object or reference
instead of the value (as it had in previous versions).
It was necessary to obtain the value.
If you comment out the code, what happens?
Tom
On Mon, Jan 26, 2004 at 10:48:07AM +0100, Steffen Goeldner wrote:
Hi Jan,
the fetch method of DBD::ADO::st contains the following lines:
my $row =
[ map { $rs-Fields($_-{Name})-{Value} } @$ado_fields ];
# Jan Dubois [EMAIL PROTECTED] addition to handle changes
# in Win32::OLE return of Variant types of data.
foreach (@$row) {
$_ = $_-As( Win32::OLE::Variant::VT_BSTR() )
if UNIVERSAL::isa($_, 'Win32::OLE::Variant');
}
where $rs is an ADO Recordset. Is the foreach loop really
necessary, i.e. can a Field value be a Win32::OLE::Variant?
I thought the Value method always returns a Perl value?
What does the comment mean, i.e. what are these 'changes in
Win32::OLE return of Variant types of data'?
Steffen
Re: DBI Driver Tests
Thanks for all the input. I'm going to attempt to write a draft outlining the goals and basic design this weekend. On Thu, Jan 22, 2004 at 11:24:59PM -0500, Jeff Urlwin wrote: Just my initial thought. An intended SCOPE would be nice for those of us who would like to contribute, but don't have a lot of time to do it. I expect your DBD::ODBC tests will provide valuable input to Tom's design. I hope so. If nothing else, to see some of the things that I had to deal with. Some drivers don't report support for SQL_INTEGER, but do support SQL_SMALLINT because their integers do not reach the range of the ODBC spec. I suspect that since it seems that some people are using DBD::ODBC to get type info from their DB (thanks Steffan!), I suspect that issue will be perpetuated. I went through similar challenges with DBD::ADO test. Of course I started with DBD::ODBC and DBD::Oracle tests :-) Tom
Re: Conformance test script for drivers
As this is going to be part of DBI, whatever version control DBI uses, the conformance tests will also use. Hopefully that'll make it more available to other who want to contribute. Tom On Sun, Jan 18, 2004 at 01:20:11PM -0500, Jeff Urlwin wrote: May I suggest that we make this either part of DBI or DBI::DriverTest and that it's available via Subversion or CVS so that many can contribute? I may be able to contribute some of my tests, for example, but I certainly do not have time to be responsible for it. Regards, Jeff -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Saturday, January 17, 2004 9:17 AM To: DBI developers Subject: Re: Conformance test script for drivers On Fri, Jan 16, 2004 at 07:48:15PM -0500, Thomas A. Lowery wrote: Any volunteers to work on this? I will. Wonderful! Many thanks Tom. It's hard to overestimate how important this will be. Especially with DBI v2, parrot, and perl6 on the horizon. Tim.
Re: Conformance test script for drivers
On Sun, Jan 18, 2004 at 11:27:32AM +, Tim Bunce wrote: On Sat, Jan 17, 2004 at 04:51:36PM +0100, H.Merijn Brand wrote: On Sat 17 Jan 2004 15:16, Tim Bunce [EMAIL PROTECTED] wrote: On Fri, Jan 16, 2004 at 07:48:15PM -0500, Thomas A. Lowery wrote: Any volunteers to work on this? I will. Wonderful! Many thanks Tom. Yes. Great. Send the prototype to me [...] Before we get that far there should be some discussion on the design first. Shall I start a new thread for the design discussion? Tom
Re: Conformance test script for drivers
Any volunteers to work on this? I will. Tom
Re: [Patch] Minor Patch for DBD::ExampleP
Yep it worked. Here's a new patch:
--- ExampleP.pm.orig2003-09-11 07:41:25.0 -0400
+++ ExampleP.pm 2003-09-11 22:28:13.0 -0400
@@ -358,10 +358,10 @@
# either return dynamic values that cannot be precomputed
# or fetch and cache attribute values too expensive to prefetch.
if ($attrib eq 'TYPE'){
- return [ @DBD::ExampleP::stattypes{ @{ $sth-{NAME_lc} } } ];
+ return [ @DBD::ExampleP::stattypes{ @{ $sth-FETCH(q{NAME_lc}) } } ];
}
elsif ($attrib eq 'PRECISION'){
- return [ @DBD::ExampleP::statprec{ @{ $sth-{NAME_lc} } } ];
+ return [ @DBD::ExampleP::statprec{ @{ $sth-FETCH(q{NAME_lc}) } } ];
}
elsif ($attrib eq 'ParamValues') {
my $dbd_param = $sth-{dbd_param} || [];
On Thu, Sep 11, 2003 at 05:11:32PM +0100, Tim Bunce wrote:
Thanks. But when/why is $sth-{NAME_lc} undefined?
I suspect the right fix is to change $sth-{NAME_lc}
to $sth-FETCH('NAME_lc') to trigger the magic that
handled the _lc suffix. Could you try that for me?
Tim.
On Thu, Sep 11, 2003 at 08:15:28AM -0400, Thomas A. Lowery wrote:
Tim,
Here's a minor patch for DBD::ExampleP to fix:
https://rt.cpan.org/Ticket/Display.html?id=2192
Use of uninitialized value in array dereference at
/opt/perl_5.8.0/lib/sun4-solaris-thread-multi/DBD/ExampleP.pm line 360.
Tom
--- ExampleP.pm.orig2003-09-11 07:41:25.0 -0400
+++ ExampleP.pm 2003-07-29 20:53:22.0 -0400
@@ -357,10 +357,15 @@
# In reality this would interrogate the database engine to
# either return dynamic values that cannot be precomputed
# or fetch and cache attribute values too expensive to prefetch.
+
if ($attrib eq 'TYPE'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::stattypes{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'PRECISION'){
+ return [] unless (defined $sth-{NAME_lc}
+ and scalar @{$sth-{NAME_lc}});
return [ @DBD::ExampleP::statprec{ @{ $sth-{NAME_lc} } } ];
}
elsif ($attrib eq 'ParamValues') {
[upload@pause.perl.org: PAUSE indexer report TLOWERY/DBD-ADO-2.7.tar.gz]
Odd messages received from PAUSE for the DBD-ADO release. Hmmm, looks like you own these. When you've moment change permissions to TLOWERY please. Looks like we'll have conflicts with DBI::Shell modules also. Is the permissions a new function of PAUSE? Can we both have permissions to the same modules? Tom DBD::ADO::db version: 2.7 in file: DBD-ADO-2.7/lib/DBD/ADO.pm status: Not indexed because permissions missing. Visit PAUSE and click View Permissions to find the legitimate maintainer(s). DBD::ADO::dr version: 2.7 in file: DBD-ADO-2.7/lib/DBD/ADO.pm status: Not indexed because permissions missing. Visit PAUSE and click View Permissions to find the legitimate maintainer(s). DBD::ADO::st version: 2.7 in file: DBD-ADO-2.7/lib/DBD/ADO.pm status: Not indexed because permissions missing. Visit PAUSE and click View Permissions to find the legitimate maintainer(s).
Announce: DBD::ADO 2.7
OK, tests fixed, new version is available. http://stlowery.net/DBD-ADO-2.7.tar.gz
Re: Announce: DBI 1.38 release candidate
All tests successful, 6 tests skipped. Files=34, Tests=1372, 84 wallclock secs (70.24 cusr + 4.02 csys = 74.26 CPU) Perl: 5.008 OS : linux DBI : 1.38 DBD::mysql : 2.1021 DBD::Sponge : 11.09 DBD::Proxy : 0.2004 DBD::Pg : 1.31_3 DBD::Oracle : 1.14 DBD::Multiplex : 0.9 DBD::File : 0.2001 DBD::ExampleP : 11.10 DBD::CSV: 0.2002
Re: DBD::ADO 2.6: types in metadata result sets
Thanks! I've just successfully rebuilt my Windows Machine (from NT4 -
2000 replacing the crashed hd and non-functional cdrom), so hopefully I can
apply this patch and fix the bug with undef/null values in parameters in the
next week or so.
Thomas
On Mon, Aug 18, 2003 at 12:18:27PM +0200, Steffen Goeldner wrote:
Hi Thomas,
attached is a small patch to provide correct types
in metadata result sets.
Steffen
*** ADO.orig Sat Nov 09 21:08:44 2002
--- ADO.pmSun Aug 17 22:45:38 2003
***
*** 1141,1148
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1 })-prepare(
! $QueryType, { rows = [EMAIL PROTECTED], NAME =
! [ qw( TABLE_CAT TABLE_SCHEM TABLE_NAME COLUMN_NAME DATA_TYPE
TYPE_NAME COLUMN_SIZE BUFFER_LENGTH DECIMAL_DIGITS NUM_PREC_RADIX NULLABLE REMARKS
COLUMN_DEF SQL_DATA_TYPE SQL_DATETIME_SUB CHAR_OCTET_LENGTH ORDINAL_POSITION
IS_NULLABLE ) ]});
}
sub primary_key_info {
--- 1141,1150
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1 })-prepare(
! $QueryType, { rows = [EMAIL PROTECTED]
! , NAME = [ qw( TABLE_CAT TABLE_SCHEM TABLE_NAME COLUMN_NAME
DATA_TYPE TYPE_NAME COLUMN_SIZE BUFFER_LENGTH DECIMAL_DIGITS NUM_PREC_RADIX NULLABLE
REMARKS COLUMN_DEF SQL_DATA_TYPE SQL_DATETIME_SUB CHAR_OCTET_LENGTH ORDINAL_POSITION
IS_NULLABLE ) ]
! , TYPE = [12, 12,12, 12,
5, 12, 4,4, 5, 5, 5,
12,12,5, 5,4, 4,
12 ]
! });
}
sub primary_key_info {
***
*** 1177,1184
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1
})-prepare(
! $QueryType, { rows = [EMAIL PROTECTED], NAME =
! [ qw( TABLE_CAT TABLE_SCHEM TABLE_NAME COLUMN_NAME KEY_SEQ
PK_NAME ) ]});
}
--- 1179,1188
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1
})-prepare(
! $QueryType, { rows = [EMAIL PROTECTED]
! , NAME = [ qw( TABLE_CAT TABLE_SCHEM TABLE_NAME
COLUMN_NAME KEY_SEQ PK_NAME ) ]
! , TYPE = [12, 12,12,
12, 5, 12 ]
! });
}
***
*** 1223,1230
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1 })-prepare(
! $QueryType, { rows = [EMAIL PROTECTED], NAME =
! [ qw( PKTABLE_CAT PKTABLE_SCHEM PKTABLE_NAME PKCOLUMN_NAME
FKTABLE_CAT FKTABLE_SCHEM FKTABLE_NAME FKCOLUMN_NAME KEY_SEQ UPDATE_RULE DELETE_RULE
FK_NAME PK_NAME DEFERRABILITY ) ]});
}
sub type_info_all {
--- 1227,1236
$conn-{CursorLocation} = $tmpCursorLocation;
DBI-connect('dbi:Sponge:','','', { RaiseError = 1 })-prepare(
! $QueryType, { rows = [EMAIL PROTECTED]
! , NAME = [ qw( PKTABLE_CAT PKTABLE_SCHEM PKTABLE_NAME
PKCOLUMN_NAME FKTABLE_CAT FKTABLE_SCHEM FKTABLE_NAME FKCOLUMN_NAME KEY_SEQ
UPDATE_RULE DELETE_RULE FK_NAME PK_NAME DEFERRABILITY ) ]
! , TYPE = [ 12, 12, 12,
12, 12, 12, 12, 12, 5, 5,
5, 12, 12,5 ]
! });
}
sub type_info_all {
Re: fetching with report breaks, totals and subtotals (was: More on testing cursors in Perl and PL/SQL)
On Mon, Dec 30, 2002 at 12:07:40PM +, Tim Bunce wrote: On Sun, Dec 29, 2002 at 06:11:28PM -0800, Jared Still wrote: One more thing: One of my long time wished for modules is one that emulates some of the more useful features of SQL*Plus, namely report breaks, totals and subtotals. I've finally actually started on it. Would you be interested in seeing that? Yes. And the design/API as much, if not more, than the actual code. It's probably worth discussing on dbi-users or dbi-dev [CC'd to dbi-dev for now]. I know Tom Lowery is working on extending the DBI::Shell with sufficient functionality to emulate SQL*Plus. I've the basic break support added to DBI::Shell::SQLMinus, syntax: /break on id skip X Needs more work and documentation, but it's a start. Tom -- Thomas A. Lowery See DBI/FAQ http://www.xmlproj.com/cgi/fom.cgi
Re: ANNOUNCE: DBD::Pg 1.20
On Sat, Nov 30, 2002 at 07:38:52PM -0600, Dave Rolsky wrote: On Sat, 30 Nov 2002, Thomas A. Lowery wrote: On Sat, Nov 30, 2002 at 10:47:09AM -0700, Jason E. Stewart wrote: Dave Rolsky [EMAIL PROTECTED] writes: I found a bug in the -tables method. It includes all the system tables. A patch is at the bottom of the message. I modified the tables and table_info methods to include the system tables. Why? It's really pretty irritating since they _always_ will be included. And you didn't modify the docs to match, since they still say that they're _not_ included. My mistake on the docs, I'll correct them. I find it irritating that the systems tables are NOT included. Is there a good reason to exclude them? The advance meta data methods provide a means to write portable code across the different drivers, let's not leave DBD::Pg out. Tom -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: ANNOUNCE: DBD::Pg 1.20
On Sat, Nov 30, 2002 at 10:47:09AM -0700, Jason E. Stewart wrote: Dave Rolsky [EMAIL PROTECTED] writes: I found a bug in the -tables method. It includes all the system tables. A patch is at the bottom of the message. I modified the tables and table_info methods to include the system tables. I'd like to offer a test patch but I don't know exactly what you'd expect to find in the schema during testing. t/01setup.t has the following: my $sql = SQL; CREATE TABLE test ( id int, name text, val text, score float, date timestamp default 'now()' ) SQL -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: ANNOUNCE: DBD::Pg 1.20
On Sat, Nov 30, 2002 at 12:51:14PM -0800, David Wheeler wrote: On Saturday, November 30, 2002, at 12:47 PM, Thomas A. Lowery wrote: I modified the tables and table_info methods to include the system tables. Okay, so the question is, is this a desirable change? Do people want to know about the system tables or not? Is there a standard answer to this question? Should we have a separate method that includes system tables? IMHO: a Pg only function is not a good option. It's very difficult to write portable code. The DBI doc reads: tables Warning: This method is experimental and may change. @names = $dbh-tables( $catalog, $schema, $table, $type ); @names = $dbh-tables;# deprecated Simple interface to table_info( ). Returns a list of matching table names, possibly including a cata log/schema prefix. See table_info for a description of the parameters. If $dbh-get_info(29) returns true (29 is SQL_IDENTIFIER_QUOTE_CHAR) then the table names are constructed and quoted by quote_identifier to ensure they are usable even if they contain whitespace or reserved words etc. With the table method including catalog, schema, and type, I can see no reason to exclude the system tables. -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: DBD::Pg - a strong request
I've found pg_config the best solution to determine where things are
installed.
pg_config provides information about the installed version of PostgreSQL.
Usage: pg_config --bindir | --includedir | --includedir-server | --libdir |
--pkglibdir | --configure | --version
Operation modes:
--bindir show location of user executables
--includedir show location of C header files of the client
interfaces
--includedir-server show location of C header files for the server
--libdir show location of object code libraries
--pkglibdir show location of dynamically loadable modules
--configure show options given to 'configure' script when
PostgreSQL was built
--version show the PostgreSQL version and exit
However, on that note, just installing the darn module may not be possible
without skipping the tests.
There are additional pieces of information needed:
$ENV{DBDPG_TEST_DB}
$ENV{DBDPG_TEST_HOST}
$ENV{DBDPG_TEST_USER}
$ENV{DBDPG_TEST_PASS}
(prevents mucking up a real database)
Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
tests. Without the correct setup installing from CPAN will fail.
Tom
Report bugs to [EMAIL PROTECTED].
On Sun, Nov 24, 2002 at 04:33:15PM -0600, Dave Rolsky wrote:
On Sun, 24 Nov 2002, Randal L. Schwartz wrote:
Jason Absolutely. It is one of the first things that was discussed. The
Jason decision was to use App::Info during the configuration phase.
Well, I hope it just falls back to doing the right thing if the lib
and include file are found in the same places Perl looks for
everything else.
Don't ask questions. Just install the darn module.
It looks for pg_config, which if found will tell it what it needs. I'd
prefer that it ask questions rather than the current irritating approach
of just giving up completely, though.
--
Thomas A. Lowery
See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
DBD::Pg CVS version.
Hey All, I just updated with recent CVS version of DBD::Pg from GBorg. The first thing I noticed is perl Makefile.PL croaked because I didn't have an App::Info ... module installed. IMHO, this should be removed as it is not part of DBI nor truly required by the DBD::Pg. I committed a new MANIFEST (the previous one got trashed IIRC). Also, I committed a patch to Pg.pm to correct some issues with the meta data. Questions, are we, the developers suppose to commit or simply submit patch files using the patch interface? Tom p.s. My first PostgreSQL, Perl, PHP project goes live on Monday. Hopefully the company will allow me to release a we used these open source tools statement. -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: [INTERFACES] DBD::PostgreSQL compile time /run time version
On Tue, Nov 19, 2002 at 03:13:49PM -0800, David Wheeler wrote: On Tuesday, November 19, 2002, at 04:19 AM, Peter Haworth wrote: as well as adding the 7.3 behavior, and deciding which to do based on the server version? I think I'd rather do it at compile-time, depending on the PosgreSQL libraries available. Folks who compile against 7.3 and then connect to 7.2 get what they ask for, IMO. Ack! I hope this isn't true. Think about it: My development machine has the latest and greatest PostgreSQL installed (along with Perl/DBI/dbish), I'm testing the difference between PostgreSQL 7.2 and 7.3 in my application. Time to connect with the production server to research a difference (the 7.2 base). Do I need to maintain two copies of DBD::Postgres (or DBD::Pg ... not sure of the new name) one compiled for 7.2 and one for 7.3? I understand the pain of supporting different functions for different versions. Tom -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: [INTERFACES] DBD::PostgreSQL
This is great to hear ... possible name of PgXS? (not that the current version isn't using XS), allows both Pg and the new Pg (along with PgSPI) to be installed at once. On Sun, Nov 17, 2002 at 07:00:30PM -0800, David Wheeler wrote: programmed C before; and c) I didn't want to just totally hork the DBD::Pg sources, I took it upon myself to try creating a new PostgreSQL driver from scratch. Learning under fire, the best way! * In DBD::Pg's dbdimp.c, the dbd_db_commit() function attempts a commit, and if it's successful, it then starts another transaction. Is this the proper behavior? The other DBDs I looked at don't appear to BEGIN a new transaction in the dbd_db_commit() function. Yes, when AutoCommit is on, each statement is committed after execution. DBD::ADO uses an ADO function that starts a new transaction after a successful commit or rollback of the current. It's switching between the two states that gets difficult to handle (also supporting database types that do not support transactions). * A similar question applies to dbd_db_rollback(). It does a rollback, and then BEGINs a new transaction. Should it be starting another transaction there? Yes. * How is DBI's begin_work() method intended to influence commits and rollbacks? Info from the DBI doc: begin_work $rc = $dbh-begin_work or die $dbh-errstr; Enable transactions (by turning AutoCommit off) until the next call to commit or rollback. After the next commit or rollback, AutoCommit will automatically be turned on again. If AutoCommit is already off when begin_work is called then it does nothing except return an error. If the driver does not support transactions then when begin_work attempts to set AutoCommit off the driver will trigger a fatal error. See also Transactions in the FURTHER INFORMATION section below. IMHO: begin_work for Pg simply turns AutoCommit off. The AutoCommit handles committing the current transaction and starting the next. * Also in dbd_db_commit() and dbd_db_rollback(), I notice that the last return statement returns 0. Shouldn't these be returning true? Success is non-zero. However, $dbh-err is 0 or undefined. Info from DBI doc: commit $rc = $dbh-commit or die $dbh-errstr; * In DBD::Pg's dbdimp.c, the dbd_db_disconnect() function automatically does a rollback if AutoCommit is off. Should there not be some way to tell that, in addition to AutoCommit being off, a transaction is actually in progress? That is to say, since the last call to dbd_db_commit() that some statements have actually been executed? Or does this matter? IMHO: It's much safer to rollback (unconditionally) on disconnect, then attempting to manage tracking the current action taken in the transaction by the different statement handlers. * And finally, is dbd_preparse() totally necessary? I mean, doesn't PostgreSQL's PQexec() function do the necessary parsing? Jeffrey Baker mentioned to me that he was working on a new parser, and perhaps I'm missing something (because of parameters?), but I'm just trying to figure out why this is even necessary. AFAIK: All the drivers support dbd_preparse. * One more thing: I was looking at the PostgreSQL documents for the new support for prepared statements in version 7.3. They look like this: PREPARE q3(text, int, float, boolean, oid, smallint) AS SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::int); (BTW, I can see why preparsing would be necessary here!) Now, if I'm understanding this correctly, the PREPARE statement would need to have the data types of each of the parameters specified. Is this something that's done in other DBI drivers? Ouch ... that may make things ugly. It'll give you fewer nightmares if you can pass the statement to the back-end to prepare, having the back-end return the number of parameters, and data types. (I haven't looked at the 7.3 PostgreSQL documentation yet). If the back-end doesn't support this type of prepare, then you may need to pre-parse the statement to determine what placeholders are requires and attempt to determine the correct data types. Tom -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: DBD::Pg up for sale
On Mon, Oct 21, 2002 at 01:50:25PM -0600, Jason E. Stewart wrote: I joined up two days ago, got approved, checked out the code and am testing my changes to the table_info() method. I'll post my ideas here. I just uploaded a patch that begins adding meta data support to DBD::Pg based on DBI spec. It includes an enhance table_info method. T -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: DBD::Pg up for sale
On Fri, Oct 18, 2002 at 10:13:07AM -0700, David Wheeler wrote: Actually, DBD::Pg maintenance has been taken over by Bruce Momjian, on This is great news. of the PostgreSQL core developers. He set up a GBorg project page for it (with CVS access and the rest) here: http://gborg.postgresql.org/project/dbdpg/projdisplay.php I just asked Bruce where you should send them. He suggested the new DBD-Pg mail list. Here's the subscription page: It's important to not splinter the DBI Drivers development. In the past, Tim Bunce has discouraged alternate development lists in favor of using dbi-dev. I agree with this. It helps to see the history of how a driver change affects the DBI spec, since the need of one driver may truly be the need of many drivers (begin_work, ping, meta data). Tom
Re: DBD::Pg up for sale
On Wed, Oct 16, 2002 at 09:31:59AM -0600, Jason E. Stewart wrote: Jan-Pieter Cornet [EMAIL PROTECTED] writes: I'm willing to take the job if it's still available. I have already submitted some patches to DBD::Pg in the past, so I'm somewhat familiar with the code. My company (XS4ALL, who is willing to supports me in this) uses DBD::Pg in production, and I'm usually the one installing it anyway. Also, I can probably ask advice from fellow Amterdam.pm member and DBD::Unify veteran H.Merijn Brand, and my soon-to-be colleague Jos Boumans also implied that he could offer some assistance. My regular contact Email address is [EMAIL PROTECTED] That would be excellent. I would be definitely willing to help out. Is there a possibility to get the driver hosted in a public CVS server like SourceForge? That would make contributing much easier. The simplest way to get into SourceForge is to host DBD::Pg as a project, fill out the appropriate paperwork. I've DBD::ADO hosted under Orac project, just as a public resting site. I've submitted a number of patches to add meta-data support to DBD::Pg (which I'm using in a locally modified version). I'll resend them to the new maintainer if needed. I've my first project going live on Oct 28 using PostgreSQL, Perl with DBD::Pg, and PHP ... Tom -- Thomas A. Lowery
Re: column_info and other new metadata methods
Dave, I just submitted a patch that includes column_info support for Pg. It's not a 100% completed, but is a good start. The next (soon to be released) version of DBD::ADO includes support. Also, I believe DBD::ODBC supports the metadata already. I'm looking forward to DBD::Oracle ... maybe a beta Tim? I modified DBI::Shell::Completion to use the metadata for populating completion lists. Tom On Sun, Jun 02, 2002 at 12:11:50PM -0500, Dave Rolsky wrote: I can't find any drivers which implement column_info and some of the other new metadata methods. Are driver authors planning to implement these soon? I could probably provide implementations for Mysql and Pg, at least. I for one would find them _very_ useful for Alzabo. -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: DBI::PurePerl -- would you believe 100%?
On Sun, Apr 14, 2002 at 09:58:13AM -0400, Matthew O. Persico wrote: On 13 Apr 2002 11:56:33 -0700, Jeff Zucker wrote: [EMAIL PROTECTED] wrote: if Larry had wanted Perl to be able to distinguish numbers from numberlike strings he would have given us a way before B. I think that needs to be ammended to: If Larry had wanted us not to be able to distinguish numbers from numberlike strings, he wouldn't have invented Randal. Um, that's very cute, but it seems very internal to me. What are the odds that this is going to work in Perl 6? I'm not so sure I'd depend upon it. Matthew, are you implying that Perl 6 is un-inventing Randal? ;- T -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Re: New RC for DBD::ADO, Vesion 2.4_05
On Thu, Apr 11, 2002 at 09:33:33AM +0100, Simon Oliver wrote: Thomas, I've had a problem with DBD::ADO for the last few releases but haven't had time to report it. When I use warnings; I often get OLE warnings when executing a prepared statement. I have tested this against a number of datasources. I have attached the code after my signature. Provider cannot derive parameter information and SetParameterInfo has not been called. Win32::OLE(0.1502) error 0x80020009: Exception occurred in METHOD/PROPERTYGET Count at C:/Perl/site/lib/DBD/ADO.pm line 1878 Thanks Simon, I found the problem area. The fix is in 2.4_06. Tom -- Thomas A. Lowery See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
DBD::ADO RC 2.4_06
On Thu, Apr 11, 2002 at 04:43:07PM +0200, Steffen Goeldner wrote:
Attached is a small patch for column_info().
$TypeName was set before the test
$ti-{COLUMN_SIZE} = $ColSize;
Thus, if no type has a large enough COLUMN_SIZE (hypothetical
case), $TypeName may contain a wrong type name.
Now, $TypeName remains undefined in this case.
Applied ... Attached is RC 2.4_06 ... let me know.
Thanks,
Tom
--
Thomas A. Lowery
See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
DBD-ADO-2.4_06.tar.gz
Description: GNU Zip compressed data
Patches for DBD::Pg
Jeff,
I've attached two patches. Both involve the meta data returned by
DBD::Pg.
Tom
*** /usr/local/src/.cpan/build/DBD-Pg-1.11/Pg.pm.orig Tue Mar 19 20:46:56 2002
--- Pg.pm Mon Apr 8 22:36:12 2002
***
*** 146,169
sub table_info { # DBI spec: TABLE_CAT, TABLE_SCHEM, TABLE_NAME,
TABLE_TYPE, REMARKS
my($dbh) = _;
! my $sth = $dbh-prepare(
! SELECT c.reltype, u.usename, c.relname, 'TABLE', ''
! FROM pg_class c, pg_user u
! WHERE c.relkind = 'r'
! AND c.relhasrules = FALSE
! AND c.relname !~ '^pg_'
! AND c.relname !~ '^xin[vx][0-9]+'
! AND c.relowner = u.usesysid
UNION
! SELECT c.reltype, u.usename, c.relname, 'VIEW', ''
! FROM pg_class c, pg_user u
! WHERE c.relkind = 'r'
AND c.relhasrules = TRUE
AND c.relname !~ '^pg_'
AND c.relname !~ '^xin[vx][0-9]+'
AND c.relowner = u.usesysid
! ORDER BY 1, 2, 3
! ) or return undef;
$sth-execute or return undef;
$sth;
--- 146,186
sub table_info { # DBI spec: TABLE_CAT, TABLE_SCHEM, TABLE_NAME,
TABLE_TYPE, REMARKS
my($dbh) = _;
! my $sth = $dbh-prepare(qq{
! SELECT
! NULL::textAS TABLE_CAT
! , u.usename AS TABLE_SCHEM
! , c.relname AS TABLE_NAME
! , 'TABLE' AS TABLE_TYPE
! , d.description AS REMARKS
! FROM pg_user u
! , pg_class c
! LEFT OUTER JOIN pg_description AS d
! ON c.relfilenode = d.objoid and d.objsubid = 0
! WHERE c.relkind = 'r'
! AND c.relhasrules = FALSE
! AND c.relname !~ '^pg_'
! AND c.relname !~ '^xin[vx][0-9]+'
! AND c.relowner= u.usesysid
UNION
! SELECT
! NULL::text
! , u.usename
! , c.relname
! , 'VIEW'
! , d.description
! FROM
! pg_user u
! , pg_class c
! LEFT OUTER JOIN pg_description AS d
! ON c.relfilenode = d.objoid and d.objsubid = 0
! WHERE c.relkind = 'v'
AND c.relhasrules = TRUE
AND c.relname !~ '^pg_'
AND c.relname !~ '^xin[vx][0-9]+'
AND c.relowner = u.usesysid
! ORDER BY 2, 3, 4
! }) or return undef;
$sth-execute or return undef;
$sth;
***
*** 174,180
my($dbh) = _;
my $sth = $dbh-prepare(
! select relname
from pg_class
where relkind = 'r'
andrelname !~ '^pg_'
--- 191,197
my($dbh) = _;
my $sth = $dbh-prepare(
! select relname AS \TABLE_NAME\
from pg_class
where relkind = 'r'
andrelname !~ '^pg_'
***
*** 264,286
sub type_info_all {
my ($dbh) = _;
! my $names = {
! TYPE_NAME = 0,
! DATA_TYPE = 1,
! PRECISION = 2,
! LITERAL_PREFIX = 3,
! LITERAL_SUFFIX = 4,
! CREATE_PARAMS = 5,
! NULLABLE= 6,
! CASE_SENSITIVE = 7,
! SEARCHABLE = 8,
! UNSIGNED_ATTRIBUTE = 9,
! MONEY =10,
! AUTO_INCREMENT =11,
! LOCAL_TYPE_NAME =12,
! MINIMUM_SCALE =13,
! MAXIMUM_SCALE =14,
! };
# typname |typlen|typprtlen|SQL92
# --+--+-+---
--- 281,324
sub type_info_all {
my ($dbh) = _;
!
! #my $names = {
! # TYPE_NAME = 0,
! # DATA_TYPE = 1,
! # PRECISION = 2,
! # LITERAL_PREFIX = 3,
! # LITERAL_SUFFIX = 4,
! # CREATE_PARAMS = 5,
! # NULLABLE = 6,
! # CASE_SENSITIVE = 7,
! # SEARCHABLE = 8,
! # UNSIGNED_ATTRIBUTE = 9,
! # MONEY =10,
! # AUTO_INCREMENT =11,
! # LOCAL_TYPE_NAME=12,
! # MINIMUM_SCALE =13,
! #
Re: Perl GUI in HTML
On Sat, Apr 06, 2002 at 05:04:46AM -0800, Josue Garayua wrote: Thank for any comments... Yes, wrong list. This is DBI/DBD::* developers list. Tom -- Thomas A. Lowery
Who's the current maintainer for DBD::Pg?
Who is currently maintaining DBD::Pg? Tom
Re: DBD::ADO: get_info()
$row = $sth-fetch ) {
+ $cache-{$row-[0]} = [ $row ];
+ }
+ }
+ my $row = $cache-{$literal_name};
+ return $row-[1] unless wantarray; # literal value
+ return $row;
+ }
sub table_info {
my($dbh, $attribs) = _;
--
Thomas A Lowery
See DBI/FAQ http://tloweryhypermartnet
_
Do You Yahoo!?
Get your free yahoocom address at http://mailyahoocom
Re: how do I make Sprite case sensitive
Wrong list, send questions like this to dbi-users list. Tom On Wed, Jan 09, 2002 at 03:32:35PM -0500, Jose Blanco wrote: Trying to use DBD::Sprite. How do I make it case sensitive so that table and field names become what's designated in the creat table command. Any ideas? -- Thomas A. Lowery See DBI/FAQ http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: DBD::ADO - minor type
This is a good idea. I'm wondering what other Defaults to allow
for? Any which should be inherent to child handles?
Tom
On Fri, Nov 30, 2001 at 02:11:56PM +, Jacqui Caren wrote:
Rather than code prepare and do attrs across the entire
application I 'hacked' a $dbh attribute named
'adoDefaultCursorType'
This allows me to do
$dbh-{adoDefaultCursorType} = 'adOpenStatic';
and I then automatically use Open Static cursors
everywhere. Life is good and I get to go home and
eat a hot meal :-)
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: DBD::ADO: column_info
On Wed, Oct 31, 2001 at 09:26:14AM +0100, Steffen Goeldner wrote:
Attached is *not* a patch - it's a first cut and a cry for help!
I have problems mapping the ADO fields to SQL/CLI (ODBC, DBI)
fields, especially the datatype related fields.
I guess that the magic DBD::ADO::_determine_type_support() may
provide part of a solution.
Any suggestions, hints, insides, patches, ... are welcome!
BTW: It seems, that the statement handle attributes need the
same mapping.
Now that I'm looking at this again I remember why I skipped it ;-
sub column_info {
I'm beginning to remember why converting ADO to the SQL/ODBC was such a
pain: Take a simple example of what OpenSchema(adSchemaProviderType)
returns verse what the table column types return.
The Provider supports:
- data type Short: 2
- data type Long: 3
- data type Single: 4
- data type Double: 5
- data type Currency: 6
- data type DateTime: 7
- data type Bit: 11
- data type Byte: 17
- data type GUID: 72
- data type BigBinary:128
- data type LongBinary: 128
- data type VarBinary:128
- data type LongText: 130
- data type VarChar: 130
- data type Decimal: 131
However, my table columns types are
Number: 5 (adDouble)
Text: 202 (adVarWChar)
Number: 131 (adNumeric)
Number: 131 (adNumeric)
Date/Time: 7 (adDate)
Memo: 203 (adLongVarWChar)
Type 5 is supported at mytest.pl line 36
Type 202 is not supported at mytest.pl line 36
Type 131 is supported at mytest.pl line 36
Type 131 is supported at mytest.pl line 36
Type 7 is supported at mytest.pl line 36
Type 203 is not supported at mytest.pl line 36
So the Provider does not supply any information on how to support
data types adVarWChar and adLongVarWChar.
Converting from the an ADO type to the SQL/ODBC type, without support
from the provider, may be difficult.
We'll need to look at more then just the type in an attempt to map it.
As the provider above shows, the same data type may have different
column type depending on the other attributes:
TYPE_NAME
*DATA_TYPE
*COLUMN_SIZE
LITERAL_PREFIX
LITERAL_SUFFIX
CREATE_PARAMS
IS_NULLABLE
CASE_SENSITIVE
SEARCHABLE
*UNSIGNED_ATTRIBUTE
*FIXED_PREC_SCALE
*AUTO_UNIQUE_VALUE
*LOCAL_TYPE_NAME
MINIMUM_SCALE
MAXIMUM_SCALE
GUID
TYPELIB
VERSION
*IS_LONG
*BEST_MATCH
*IS_FIXEDLENGTH
I'll look at mapping the SQL_* types to ADO attributes.
Tom
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
DBI::Metadata wish list
I'd like to see some utility methods added to DBI. Something that returns an array (or reference) to all the currently supported SQL_* data types. Something that returns a hash (or reference) of SQL_* Name and Value. Something that provides a current list of all handler attributes (with current values), possible information like valid values, read-only ... Tom -- Thomas A. Lowery See DBI/FAQ http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: DBD::ADO, table_info, new style interface
Thanks Steffen! Would you provide me a test or tests for the new
table_info method?
Tom
On Thu, Oct 25, 2001 at 03:51:39PM +0200, Steffen Goeldner wrote:
Attached is a patch for DBD::ADO that provides both -
the new and the old - interfaces.
Steffen
*** DBD-ADO-2.4/lib/DBD/ADO.pmWed Oct 24 04:41:30 2001
--- ADO.pmThu Oct 25 14:37:46 2001
***
*** 638,643
--- 638,649
sub table_info {
my($dbh, $attribs) = @_;
+ $attribs = {
+ TABLE_CAT = $_[1],
+ TABLE_SCHEM = $_[2],
+ TABLE_NAME = $_[3],
+ TABLE_TYPE = $_[4],
+ } unless ref $attribs eq 'HASH';
my @tp;
my @criteria = (undef); # ADO needs at least one element in the
criteria array!
--
Thomas A. Lowery
See DBI/FAQ http://tlowery.hypermart.net
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: DBD::ADO: primary_key_info
Thanks! I've a new release of DBD::ADO ready. I'll release it in a few days. Tom -- Thomas A. Lowery See DBI/FAQ http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: DBD::ODBC-0.29 developers release
Where do download the new DBD::ODBC (developers release)? Tom -- Thomas A. Lowery See DBI/FAQ http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Maintain of DBI::Shell and DBI::Format.
Yes, I'll take over as maintainer of DBI::Shell and DBI::Format. If you feel a separate CPAN release is beneficial, then yes I'll make DBI::Shell and DBI::Format into a CPAN module. On Mon, Apr 02, 2001 at 10:31:54AM +0100, Tim Bunce wrote: Thomas, would you be happy to 'own' DBI::Shell and DBI::Format and release them as CPAN modules with test suites etc? Seems to make sense since you're putting most development into them at the moment. That way others could benefit from improvements between DBI releases and would save me having to manage patches to them. When I make DBI releases I'd just grab the latest from you or CPAN. Tim. -- Thomas A. Lowery[EMAIL PROTECTED] http://tlowery.hypermart.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [PATCH] DBD::Proxy to handle tables_info
I think, you should better describe what the actual problem is?
When using DBD::Proxy without my patch and dbish to test I get the
following error message when requesting a list of tables.
DBI::Shell: table_info failed: DBD::Proxy::st execute failed: Server returned error:
Failed to execute method CallMethod: DBD::ODBC::db prepare failed:
[Microsoft][ODBC Microsoft Access Driver]
Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or
'UPDATE'.
(SQL-37000)(DBD: st_prepare/SQLPrepare err=-1) at
t:\devstudio\myprojects\perl\dbi-1.14\lib/DBI/ProxyServer.pm line 256.
What I traced down was the statement handle being created with "SHOW
TABLES" as the SQL.
The "SHOW TABLES" thing is just, because the DBI specs require to
return a statement handle, which in turn requires a "Statement"
attribute. We could choose whatever else for "SHOW TABLES", it's
merely a placeholder.
That's later prepared, again, as a statement a new statement handle.
sub execute
undef $sth-{'proxy_data'}; The data returned from the table_info is gone.
...
my $rsth = $sth-{proxy_sth}; This is undefined.
...
if (!$rsth) {
...
($rsth, $numFields, $numParams, $names, $types, $numRows, @outParams) =
eval { $rdbh-prepare($sth-{'Statement'},
$sth-{'proxy_attr'}, $params) };
return DBI::set_err($sth, 1, $@) if $@;
Here the SQL statement "SHOW TABLES" is prepared against the remote server, it
fails returning an error message.
Does this better describe the problem?
Tom
[t:\devstudio\myprojects\perl\proxy]set DBI_AUTOPROXY=hostname=localhost;port=1234
[t:\devstudio\myprojects\perl\proxy]dbish
DBI::Shell 10.7 using DBI 1.14
WARNING: The DBI::Shell interface and functionality are
=== very likely to change in subsequent versions!
Use of uninitialized value in length at T:/Perl-5.6/site/lib/DBI/Shell.pm line 734.
Connecting to 'dbi:ODBC:photo' as ''...
@dbi:ODBC:photo /tab
DBI::Shell: table_info failed: DBD::Proxy::st execute failed: Server returned error:
Failed to execute method CallMethod: DBD::ODBC:
:db prepare failed: [Microsoft][ODBC Microsoft Access Driver] Invalid SQL statement;
:expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'. (SQL-37000)(DBD:
:st_prepare/SQLPrepare err=-1) at
:t:\devstudio\myprojects\perl\dbi-1.14\lib/DBI/ProxyServer.pm lin
[t:\devstudio\myprojects\perl\dbi-1.14]dbish
Argument "1.1.1.1 " isn't numeric in addition (+) at lib/DBI/Format.pm line 26.
DBI::Shell 10.7 using DBI 1.14
WARNING: The DBI::Shell interface and functionality are
=== very likely to change in subsequent versions!
Connecting to 'dbi:ODBC:photo' as ''...
@dbi:ODBC:photo /ta
TABLE_CAT,TABLE_SCHEM,TABLE_NAME,TABLE_TYPE,REMARKS
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'MSysAccessObjects','SYSTEM
TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'MSysACEs','SYSTEM
TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'MSysObjects','SYSTEM
TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'MSysQueries','SYSTEM
TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'MSysRelationships','SYSTEM
TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'bb','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'bbb','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'bt','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'myt','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'UserID','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'xx','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'yy','TABLE',undef
'T:\DevStudio\MyProjects\Perl\DBD-ADO\database\photos',undef,'myv','VIEW',undef
[13 rows of 5 fields returned]
@dbi:ODBC:photo
On Thu, Mar 15, 2001 at 11:13:43PM +0100, Wiedmann, Jochen wrote:
sorry for replying so late, but my time for Perl development
gets fewer and fewer.
I understand that.
I've included a patch to fix the a problem using table_info
and DBD::Proxy. Currently the DBD::Proxy attempts to execute a
statement called "SHOW TABLES".
Sorry, but that's not the case. The table_info method of
DBD::Proxy does indeed execute a table_info method on the server
side:
my($numFields, $names, $types, @rows) = eval { $rdbh-table_info(@_) };
--
Thomas A. Lowery[EMAIL PROTECTED]
http://tlowery.hypermart.net
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
[PATCH] DBD::Proxy to handle tables_info
Jochen,
I've included a patch to fix the a problem using table_info
and DBD::Proxy. Currently the DBD::Proxy attempts to execute a
statement called "SHOW TABLES". I've included a patch that
modifies the execute and fetch methods to use cached data only.
I've used (mis-used) the proxy_cache_only to mark the data as "to
read cache only". I mark the statement as INACTIVE when all the
cached data is read (and proxy_cache_only is true).
Tom
*** Proxy.pm.orig Wed Feb 09 00:29:14 2000
--- Proxy.pmThu Mar 01 23:35:56 2001
***
*** 268,274
my $sth = DBI::_new_sth($dbh, {
'Statement' = $stmt,
'proxy_attr' = $attr,
! 'proxy_params' = []
});
$sth;
}
--- 268,275
my $sth = DBI::_new_sth($dbh, {
'Statement' = $stmt,
'proxy_attr' = $attr,
! 'proxy_params' = [],
! 'proxy_cache_only' = 0,
});
$sth;
}
***
*** 307,313
'Statement' = "SHOW TABLES",
'proxy_params' = [],
'proxy_data' = \@rows,
! 'proxy_attr_cache' = { 'NAME' = $names, 'TYPE' = $types }
});
$sth-SUPER::STORE('NUM_OF_FIELDS' = $numFields);
return $sth;
--- 308,320
'Statement' = "SHOW TABLES",
'proxy_params' = [],
'proxy_data' = \@rows,
! 'proxy_attr_cache' = {
! 'NUM_OF_PARAMS' = 0,
! 'NUM_OF_FIELDS' = $numFields,
! 'NAME' = $names,
! 'TYPE' = $types
! },
! 'proxy_cache_only' = 1,
});
$sth-SUPER::STORE('NUM_OF_FIELDS' = $numFields);
return $sth;
***
*** 351,357
my $sth = shift;
my $params = @_ ? \@_ : $sth-{'proxy_params'};
! undef $sth-{'proxy_data'};
my $dbh = $sth-{'Database'};
my $client = $dbh-{'proxy_client'};
--- 358,365
my $sth = shift;
my $params = @_ ? \@_ : $sth-{'proxy_params'};
! #
! # undef $sth-{'proxy_data'};
my $dbh = $sth-{'Database'};
my $client = $dbh-{'proxy_client'};
***
*** 359,364
--- 367,381
my ($numFields, $numParams, $numRows, $names, $types, @outParams);
+ if ($sth-{'proxy_data'}) {
+ my $attrCache = $sth-{'proxy_attr_cache'};
+ $numFields = $attrCache-{'NUM_OF_FIELDS'};
+ $numParams = $attrCache-{'NUM_OF_PARAMS'};
+ $names = $attrCache-{'NAME'};
+ $types = $attrCache-{'TYPE'};
+ $numRows = scalar @{$sth-{'proxy_data'}};
+ } else {
+
if (!$rsth) {
my $rdbh = $dbh-{'proxy_dbh'};
***
*** 384,395
--- 401,414
($numRows, @outParams) = eval { $rsth-execute($params) };
return DBI::set_err($sth, 1, $@) if $@;
}
+ }
$sth-{'proxy_rows'} = $numRows;
$sth-{'proxy_attr_cache'} = {
'NUM_OF_FIELDS' = $numFields,
'NUM_OF_PARAMS' = $numParams,
'NAME' = $names
};
+
$sth-SUPER::STORE('Active' = 1) if $numFields; # is SELECT
if (@outParams) {
***
*** 428,433
--- 447,454
$sth-{'proxy_data'} = $data = [@rows];
}
my $row = shift @$data;
+
+ $sth-SUPER::STORE(Active = 0) if ( $sth-{proxy_cache_only} and !@$data );
return $sth-_set_fbav($row);
}
*fetchrow_arrayref = \fetch;
--
Thomas A. Lowery[EMAIL PROTECTED]
http://tlowery.hypermart.net
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
