DBD-ODBC-1.05: dmake.exe: Error -- Don't know how to make `config'

Although 'dmake' has no problems with empty rules (i.e. w/o recipes) in general, it complains about the DBD-ODBC-1.05 Makefile (WinNT, Borland): dmake.exe: Error -- Don't know how to make `config' I satisfied 'dmake' with a '$(NOECHO) $(NOOP)' (see attached patch). The same problem occurred in

Re: Core dump: DBD-Oracle-1.14/test.pl (perl5.6.1, WinNT, BC5.5, Oracle 8.1.7)

Steffen Goeldner wrote: > > I have a core dump in DBD-Oracle-1.14/test.pl. FYI: drwtsn32.log *> Stack Back Trace <* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012f780 77f67586 00895240 6064f221 00895240 020e524c ntdll!RtlpWaitForCriticalSectio

Core dump: DBD-Oracle-1.14/test.pl (perl5.6.1, WinNT, BC5.5, Oracle 8.1.7)

I have a core dump in DBD-Oracle-1.14/test.pl. To get a trace, I added DBI->trace(9); at line 131 (before exit). Attached is the trace file. BTW: The script does not dump if I set DBI_TRACE=1. SteffenDBI 1.37-ithread dispatch trace level set to 9 -- DBI::END >> disconnect_all DIS

Re: Release Candidate of DBD::Oracle 1.14 available

Tim Bunce wrote: > > Here's a Release Candidate of DBD::Oracle 1.14: > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.14-20020325gamma.tar.gz Sorry for the late reply (it applies to the final release too). Attached is the output of 'perl Makefile.PL'. The warning I can't find the heade

Re: Gamma release of DBD::Oracle: DBD-Oracle-1.13-20030313gamma.tar.gz

Tim Bunce wrote: > [...] > > I've attached a patch and I'd be grateful if you, or anyone else, > could test it for me. Looks good: Using C:/tmp/DBD-Oracle-1.13-gamma-patched/blib t\base...ok t\cursor.ok t\generalok t\long...ok t\ph_typeok t\plsql..ok t\reauth.skipped

Re: Gamma release of DBD::Oracle: DBD-Oracle-1.13-20030313gamma.tar.gz

Tim Bunce wrote: > > Thanks for the feedback. > > I've put an updated release candidate here: > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.13-20030313gamma.tar.gz > > Any feedback most welcome. Assuming there are no significant problems > I'll probably release this tomorrow. I encou

DBI-1.33, BC5.5 and ftime

Attached is a small patch for 'non underscore systems'. Steffen*** DBI-1.33-orig/DBI.xsThu Feb 27 01:22:44 2003 --- DBI-1.33/DBI.xs Thu Feb 27 21:36:47 2003 *** *** 1818,1823 --- 1818,1827 return when.tv_sec + (when.tv_usec / 100.0); # else/*

Re: DBI v1.32 - Code generator for $dbh->type_info_all (and Q about $dbh->type_info)

Jonathan Leffler wrote: > [...] > > Can anyone explain the bit in the type_info method description (cribbed > from the ODBC documentation, I'm sure) about 'ordered by DATA_TYPE first > and then by how closely each type maps to the corresponding ODBC SQL > data type, closest first'. SQL/CLI define

Re: Patches for DBI v1.32 - dbd_xsh.h, Driver.xst, lib/DBI/DBD.pm

Jonathan Leffler wrote: > [...] > > The only controversial bit is, I think, the changes made in the > section on Generating a GetInfo Package -- maybe Steffen should take a > look? Done. Since double quotes are required for your $driver variable, there is a potential 'double quote trap'. I attach

Re: Metadata methods in DBI

Tim Bunce wrote: > [...] > > Note that DATETIME_SUB is misspelled with > an SQL_ prefix in the docs. That's wrong. Fixed now. Really? [...] > > 2. What does the DATA_TYPE field contain when this field cont

Re: DBI 1.32 Warning

H.Merijn Brand wrote: > [...] > > It's just AIX error messages that differ: > > not ok 62 > # Test 62 got: 'opendir(foo): A file or directory in the path name does not exist.' >(t/06attrs.t at line 104) > #Expected: 'opendir(foo): No such file or directory' > # t/06attrs.t line 104 is: ok(

DBI-1.29: Wrong number of arguments in call of macro 'fp_dup'

I got the following errors (WinNT, Borland): Error E2219 DBI.xs 221: Wrong number of arguments in call of macro 'fp_dup' in function dbi_bootinit Error E2188 DBI.xs 221: Expression syntax in function dbi_bootinit Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platfo

Re: MS Access

Tim Harsch wrote: > > Forgive my naivity (or just flawed understanding) but how would one go > about creating a DBD::Access? For instance DBD::Oracle is built on OCI, > does Access have a similar network protocol? I thought that ODBC was > about the only MS supported method of communicating to

Re: DBI-1.25: dmake.exe: Error -- Don't know how to make `config'

Steffen Goeldner wrote: > > Although 'dmake' has no problems with empty rules (i.e. w/o recipes) > in general, it complains about the DBI-1.25 Makefile (WinNT, Borland): > > dmake.exe: Error -- Don't know how to make `config' > > I satisfied 

DBI-1.25: dmake.exe: Error -- Don't know how to make `config'

Although 'dmake' has no problems with empty rules (i.e. w/o recipes) in general, it complains about the DBI-1.25 Makefile (WinNT, Borland): dmake.exe: Error -- Don't know how to make `config' I satisfied 'dmake' with a '@$(NOOP)' (see attached patch). Steffen *** DBI-1.25-orig/Makefile.PL

Re: DBD::ADO RC 2.4_06

I tested DBD::ADO RC 2.4_06 with: set DBI_DSN=dbi:ADO:Provider=Microsoft.Jet.OLEDB.4.0;Data Source=mytest.mdb make test and got (among other things): t\02simpleok 7/23Use of uninitialized value in string eq at t\02simple.t line 46. Attached is a possible patch. Steffen *** DBD-

Re: DBD::ADO RC 2.4_06

Thomas A. Lowery wrote: > > Attached is RC 2.4_06 ... let me know. In t/15func.t, $dbh->column_info() will take a long time on a big database. Attached is a more specific test script for column_info(). Steffen #!/usr/bin/perl -I./t # vim:ts=2:sw=2:ai:aw:nu $| = 1; use strict; use ADOTEST()

Re: DBD::ADO: column_info

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. Steffen *** DBD-ADO-2.4

Re: DBD::Oracle: table_info, PUBLIC schema

Tim Bunce wrote: > > On Wed, Mar 20, 2002 at 12:46:39PM +0100, Steffen Goeldner wrote: > > Tim Bunce wrote: > > > > > > On Wed, Mar 20, 2002 at 10:36:47AM +0100, Steffen Goeldner wrote: > > > > Should I add 'PUBLIC' to the enumeration o

Re: DBD::Oracle: table_info, PUBLIC schema

Tim Bunce wrote: > > On Wed, Mar 20, 2002 at 10:36:47AM +0100, Steffen Goeldner wrote: > > Should I add 'PUBLIC' to the enumeration of schemas, e.g.: > > Probably. Especially if Oracle's own ODBC driver does. No, it doesn't. Should I add 'PUBLIC'

DBD::Oracle: table_info, PUBLIC schema

Tim Bunce wrote: > > On Tue, Mar 19, 2002 at 04:41:33PM +0100, Steffen Goeldner wrote: > > Thus, I'd better change: > > > > , decode( t.OWNER, 'PUBLIC', '', t.OWNER ) TABLE_SCHEM > > > > to > > > > , t.OWNER TABLE_SC

Re: catalog method arguments, empty strings ("")

Tim Bunce wrote: > > On Tue, Mar 19, 2002 at 12:20:43PM +0100, Steffen Goeldner wrote: > > Tim Bunce wrote: > > > > > > On Mon, Mar 18, 2002 at 12:05:28PM +0100, Steffen Goeldner wrote: > > > > > A more realistic example would be for drivers th

Re: catalog method arguments, empty strings ("")

Tim Bunce wrote: > > On Mon, Mar 18, 2002 at 12:05:28PM +0100, Steffen Goeldner wrote: > A more realistic example would be for drivers that return empty > strings or NULL for the catalog portion. Currently, DBD::Oracle's table_info() method returns '' -> NULL

Re: catalog method arguments, empty strings ("")

Tim Bunce wrote: > > Thanks. > > I think the DBI should follow ODBC where it differs from SQL/CLI > in areas where ODBC is not likely to change. This is probably > one of those places. O.k., I dropped the first 'XXX' (and retained that paragraph). I added a note that ODBC and SQL/CLI differ and

catalog method arguments, empty strings ("")

Steffen Goeldner wrote: > > P.S.: It seems I'll have TO DO some 'empty string' research. This is yet another case where ODBC and SQL/CLI differ :-( ODBC is quite clear about pattern value arguments: <http://msdn.microsoft.com/library/en-us/odbc/htm/odbcpat

Re: SQL_ATTR_METADATA_ID and undef vs "" vs "%" etc

Tim Bunce wrote: > > On Mon, Mar 11, 2002 at 05:46:01PM +0100, Steffen Goeldner wrote: > > + =head2 Catalog Functions > > + > > + All catalog functions accept arguments in order to restrict the result sets. > > + Passing C to an optional argument does not const

DBD::Oracle, Catalog Functions, ESCAPE

> + Some arguments in the catalog functions accept B (strings > + containing '_' and/or '%'), e.g. the C<$table> argument of C. Running some tests with 'pattern value arguments', I encountered missing ESCAPE characters in the implementation of the DBD::Oracle catalog functions. The attached patch

Re: DBD::::GetInfo generator

Jeff Zucker wrote: > > Steffen Goeldner wrote: > > > > > The order of options for SQL_SQL92_PREDICATES and for > > > SQL_STRING_FUNCTIONS (not SQL92_STRING...) are different in your Local > > > directory than they are in the MSDN ODBC docs. > &g

Re: SQL_ATTR_METADATA_ID and undef vs "" vs "%" etc

Tim Bunce wrote: > > Steffen (and anyone else interested), > > I think we need to mention SQL_ATTR_METADATA_ID in the DBI docs > somewhere (even though we don't include an API for it) because we're > assuming that (for ODBC drivers) it has a certain value. > > Also, I think we need to document

Re: DBD::::GetInfo generator

Jeff Zucker wrote: > > Hi Steffen, > > I've used your fine scripts to create and test $dbh->get_info() via > DBD::CSV. It works great. I've noticed two minor discrepencies between > the documentation I have and the way the script operates. > > The order of options for SQL_SQL92_PREDICATES and

Re: indentifier case

Jeff Zucker wrote: > > Tim Bunce wrote: > > > > On Mon, Mar 04, 2002 at 08:50:45AM -0800, Jeff Zucker wrote: > > > > > Hmm, I just checked the SQL92 standard and if I'm reading it correctly > > > the situation is ugly. Section 5.2.13 appears to say that a regular > > > identifier and a delimited

Re: SQL_ATTR_METADATA_ID and undef vs "" vs "%" etc

Tim Bunce wrote: > > Steffen (and anyone else interested), > > I think we need to mention SQL_ATTR_METADATA_ID in the DBI docs > somewhere (even though we don't include an API for it) because we're > assuming that (for ODBC drivers) it has a certain value. > > Also, I think we need to document

Re: DBD::ODBC: get_info(), KEYWORDS truncated

[EMAIL PROTECTED] wrote: > > On 05-Mar-2002 Steffen Goeldner wrote: > > Currently, long get_info() return values (e.g. SQL_KEYWORDS) > > are truncated. > > That's because the buffer has a static size of 256. > > The attached patch allocates the buffer dynamical

DBD::ODBC: get_info(), KEYWORDS truncated

Currently, long get_info() return values (e.g. SQL_KEYWORDS) are truncated. That's because the buffer has a static size of 256. The attached patch allocates the buffer dynamically and reallocates it if needed. Steffen *** DBD-ODBC-0.38-orig/dbdimp.c Tue Feb 12 19:11:56 2002 --- dbdimp.cMon

Re: DBD::ADO: get_info()

Steffen Goeldner wrote: > > Tim Bunce wrote: > > > > On Fri, Feb 08, 2002 at 03:16:38PM +0100, Steffen Goeldner wrote: > > > > > > > Ok. Or, I'm thinking about a method ado_schema_dbinfo_literal(), caching > > > all data of the adSchemaDBI

Re: DBD::::GetInfo generator

Steffen Goeldner wrote: > > Here is a first cut; test it, stress it, tell me what you think! Gen_DBD_foo_GetInfo.pl is still the same, but I - added %ReturnTypes - added %ReturnValues - added a Format() method - added an Explain() method - added GetInfoAll.pl - added e

DBD::Oracle: $sth->{TYPE}

Steffen Goeldner wrote: > > Tim Bunce wrote: > > > > On Thu, Feb 21, 2002 at 12:14:31PM +0100, Steffen Goeldner wrote: > > > > Should type_info_all() depend on ora_server_version(), > > > DBD::Oracle::ORA_OCI() or both? > > > > Both I think,

Re: DBD::ODBC: connect() attributes

Jeff Urlwin wrote: > > Are you not getting ODBC 3.x behavior by default? Yes, at least for the Oracle ODBC driver. In the past I used MS ODBC Test to capture test data like where I could set SQL_ATTR_ODBC_VERSION. Now it's possible to do it with DBD::O

Re: DBD::Oracle: type_info_all()

Tim Bunce wrote: > > On Thu, Feb 21, 2002 at 12:14:31PM +0100, Steffen Goeldner wrote: > > Should type_info_all() depend on ora_server_version(), > > DBD::Oracle::ORA_OCI() or both? > > Both I think, since you need both to be >=8 to be able to use the > types in

DBD::ODBC: connect() attributes

The attached patch makes it possible to choose the ODBC version. E.g.: my $dbh = DBI->connect( ..., { odbc_version => 3 } ) directs the driver to exhibit ODBC 3.x behavior. Steffen diff -bc DBD-ODBC-0.38-orig/ODBC.pm DBD-ODBC-0.38/ODBC.pm *** DBD-ODBC-0.38-orig/ODBC.pm Tue Feb 12 17:17:36

DBD::Oracle: type_info_all()

Since DBI supports the SQL/CLI LOB datatypes - SQL_CLOB and - SQL_BLOB and DBI supports the temporal datatype - SQL_TYPE_TIMESTAMP and DBD::Oracle has ora_server_version(), we could provide a more specific type_info_all() (see attached patch). Should type_info_all() depend on ora_server_ve

DBD::::GetInfo generator (was: quoted_identifier and get_info)

'CODE'; return $v; } Please replace with the name of your driver. =head1 SEE ALSO DBI, DBD::ODBC =head1 COPYRIGHT Copyright (c) 2002 Steffen Goeldner. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl it

Re: :ODBC: 02simple.t, core dump

Jeff Urlwin wrote: > > Steffen, > > Thanks, but, er, why, I wonder? Do you have tracing on when using one of > the machines? Do you have a different ACCESS driver? Really, I have no idea. If I encounter any differences, I'll tell you ... Steffen

DBD::ODBC: 02simple.t, core dump

I have a core dump at the end of 02simple.t (global destruction???). It occurs deterministic on on maschine, not reproduceable on another one (don't ask why): My env: WinNT 4.0 perl 5.6.1 DBI 1.21 DBD-ODBC-0.38 DBMS: ACCESS The attached patch fixes that. Steffen *** DBD-ODBC-0.38-orig/t

Re: DBD::ODBC: get_info(), strange results

Jeff Urlwin wrote: > > Steffen, > > I can't seem to find DBI::Const??? I checked CPAN and to see if my DBI > distribution had it. > > Any pointers would be welcome. Oh, sorry! DBI::Const was part of an earlier DBI patch: but never found the way into a

Re: DBD::ODBC: get_info(), strange results

Steffen Goeldner wrote: > > Steffen Goeldner wrote: > > > > DBD::ODBC's get_info() method returns strange results for some > > info types, e.g.: > > > > SQL_XOPEN_CLI_YEAR 1 892942641 > > > > instead of > > > > SQL_XOPE

Re: DBD::ODBC: get_info(), strange results

Steffen Goeldner wrote: > > DBD::ODBC's get_info() method returns strange results for some > info types, e.g.: > > SQL_XOPEN_CLI_YEAR 1 892942641 > > instead of > > SQL_XOPEN_CLI_YEAR 1 1995 > > I'm quite sure the attached patch

DBD::ODBC: get_info(), strange results

DBD::ODBC's get_info() method returns strange results for some info types, e.g.: SQL_XOPEN_CLI_YEAR 1 892942641 instead of SQL_XOPEN_CLI_YEAR 1 1995 I'm quite sure the attached patch fixes that. Steffen *** DBD-ODBC-0.37-orig/dbdimp.c Sun Feb 10 19:34:36 2002 --- DBD-ODBC-0.37

Re: quoted_identifier and get_info

Tim Bunce wrote: > > p.s. Steffen, any chance you could produce a chunk of code that'll > connect to a DSN (specified on the command line), query all the > get_info values and dump the results to stdout as a DBDGetInfo > module? Shouldn't be a big modification from the scripts you've > obvi

Re: DBD::ADO: get_info()

Tim Bunce wrote: > > On Fri, Feb 08, 2002 at 03:16:38PM +0100, Steffen Goeldner wrote: > > > > Ok. Or, I'm thinking about a method ado_schema_dbinfo_literal(), caching > > all data of the adSchemaDBInfoLiterals pseudo-table, ... > > Attached are some resul

Re: DBD::ADO: get_info()

Tim Bunce wrote: > > On Thu, Feb 07, 2002 at 11:13:22AM +0100, Steffen Goeldner wrote: > > + sub sql_identifier_quote_char { > > + my $dbh = shift; > > + my $sth = $dbh->func('adSchemaDBInfoLiterals','OpenSchema'); > > + while

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > Great stuff, I've applied your patch to the attached copy. I haven't had > to much time to test. > > I did change the where the ado_consts, myado_types* to attributes of > the database handler, instead of package variable. I was having some > "score" problems. > > On

Re: DBD::ADO: get_info(), Jet

Attached are the results for the Microsoft.Jet.OLEDB.4.0 Provider. The ODBC driver http:[EMAIL PROTECTED]/msg00525.html and DBD::ADO return quite different results (for various reasons): ODBC DBD::ADO - ---

Re: DBD::ADO: get_info(), MSDAORA

Attached are the results for the MSDAORA Provider. Steffen SQL_CATALOG_LOCATION 2 SQL_CATALOG_TERM Database Link SQL_CONCAT_NULL_BEHAVIOR 1 SQL_DATA_SOURCE_NAME tst SQL_DBMS_NAME Oracle SQL_DBMS_VER

Re: DBD::ADO: get_info()

Tim Bunce wrote: > > On Wed, Feb 06, 2002 at 09:48:54AM +0100, Steffen Goeldner wrote: [...] > > I'm not sure if we can cache *every* value. Is it possible that a DBMS > > allows to change some properties at runtime (something like 'ALTER > > SESSION SET ...&#

Re: DBD::ADO: get_info()

Tim Bunce wrote: > > On Tue, Feb 05, 2002 at 04:37:48PM +0100, Steffen Goeldner wrote: > > + sub sql_identifier_quote_char { > > + my $dbh = shift; > > + my $sth = $dbh->func('adSchemaDBInfoLiterals','OpenSchema'); > > + while ( my

Re: DBD::ADO: get_info()

Similar to DBD::Oracle, here a implementation for DBD::ADO. Steffen diff -Nrc DBD-ADO-2.4.02-orig/lib/DBD/ADO/GetInfo.pm DBD-ADO-2.4.02/lib/DBD/ADO/GetInfo.pm *** DBD-ADO-2.4.02-orig/lib/DBD/ADO/GetInfo.pm Thu Jan 01 01:00:00 1970 --- DBD-ADO-2.4.02/lib/DBD/ADO/GetInfo.pm Mon Feb 04 20:

Re: DBD::Oracle: get_info()

Tim Bunce wrote: > > Umm, carrying on from there... move %get_info_constants into DBD::Oracle::GetInfo > and make get_info do: > > sub get_info { > my($dbh, $info_type) = @_; > require DBD::Oracle::GetInfo; > my $v = $DBD::Oracle::GetInfo::info{int($info_type)}; > $v = &$v($dbh

Re: DBD::Oracle: get_info()

Tim Bunce wrote: > > On Fri, Feb 01, 2002 at 09:21:09AM +0100, Steffen Goeldner wrote: > > A new patch for DBD::Oracle: > > > > - get_info() now takes a numeric value > > - SQL_DBMS_VERSION is supported > > > > More info types if desired. (I don

Re: DBD::Oracle: get_info()

A new patch for DBD::Oracle: - get_info() now takes a numeric value - SQL_DBMS_VERSION is supported More info types if desired. (I don't like a blindfold adoption of the Oracle ODBC driver results.) Steffen *** DBD-Oracle-1.12.orig/Oracle.pm Fri Aug 31 18:27:18 2001 --- Oracle.pm Thu

Re: SQL GetInfo (Was Re: SQL Implementation Specifics)

Jeff Zucker wrote: > > > 2. I seem to remember a GetInfo( 'All' ) call from somewhere. My test cases contain the string 'Get Info All'. It's an odbcte32.exe menu command. I guess they loop over all info-types inte

Re: SQL GetInfo (Was Re: SQL Implementation Specifics)

Tim Bunce wrote: > > On Tue, Jan 29, 2002 at 02:36:54PM -0800, Jeff Zucker wrote: > > > * The $info_type parameter is an integer. These integers can be > > found in the docs for ODBC or SQL/CLI > > Yes. > > > or in the DBI %GetInfo > > which has as keys the names of the constants and a

Re: SQL GetInfo (Was Re: SQL Implementation Specifics)

Jeff Zucker wrote: > > Tim Bunce wrote: > > > > I'd strongly suggest that the configuration be implemented in a way > > compatible with ODBC GetInfo, as far as possible. Which basically > > means use something like a hash where the key is an integer and the > > value is the corresponding value of

Re: DBD::Oracle: get_info(), SQL_DBMS_VERSION

Tim Bunce wrote: > > > SELECT version > >FROM product_component_version > > WHERE product LIKE 'Oracle%' > > should be a quite portable way. > > I'd be a little nervous of that returning more than one row. > But lets wait and see if anyone complains :) How about a test: #!perl -w sub o

Re: DBD::Oracle: get_info(), SQL_DBMS_VERSION

Tim Bunce wrote: > > > *** DBD-Oracle-1.12.orig/Oracle.pmFri Aug 31 18:27:18 2001 > > --- Oracle.pm Fri Jan 25 11:37:32 2002 > > *** > > *** 580,585 > > --- 580,601 > > return 1; > > } > > > > + sub _server_version { > > Might as well call it ora_server_

Re: DBD::Oracle: get_info(), SQL_DBMS_VERSION

Steffen Goeldner wrote: > > Steffen Goeldner wrote: > > > > I think, all currently supported information types are > > stable across most Oracle releases. Other types may > > depend on a specific version, thus SQL_DBMS_VERSION is > > a top entry in the TODO li

Re: DBD::Oracle: get_info(), SQL_DBMS_VERSION

Steffen Goeldner wrote: > > I think, all currently supported information types are > stable across most Oracle releases. Other types may > depend on a specific version, thus SQL_DBMS_VERSION is > a top entry in the TODO list. I guess OCIServerVersion > can help in obtaining

Re: SQL Protocol Spec

Flowers, Jay wrote: > > I am not sure if this is the right place to be asking such a question? > > I am writing a sniffer in perl and would like to be able to decode data in > TCP packets from SQL clients and servers. I was wondering if there was part > of the DBI that I could use to decode the

Re: SQL/CLI: new draft

Steffen Goeldner wrote: > > SQL - Part 3: Call-Level Interface (SQL/CLI) moved from CD to FCD: > > ><http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/7E3B41486BD99C3488256B410064C877/$FILE/32N0744T.PDF> > > Good news: SQL_BIT was removed from sqlcli.h!

Re: SQL/CLI: new draft

Steffen Goeldner wrote: > > SQL - Part 3: Call-Level Interface (SQL/CLI) moved from CD to FCD: > > ><http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/7E3B41486BD99C3488256B410064C877/$FILE/32N0744T.PDF> > > A DBI patch is on the way ... New URL, new pa

SQL/CLI: new draft

SQL - Part 3: Call-Level Interface (SQL/CLI) moved from CD to FCD: Good news: SQL_BIT was removed from sqlcli.h! A DBI patch is on the way ... Steffen

Re: quote_identifier (was Re: DBI Attributes)

Jonathan Leffler wrote: > > I thought that table_info was supposed to return the data in a usable > format, so that you didn't need to do more than replace one of the items > from table_info (or maybe the dot-separated concatenation of some > sequence of non-empty items) into the FROM clause. If

Re: DBI: get_info() constants

Tim Bunce wrote: > > On Mon, Nov 26, 2001 at 09:21:49PM +, Tim Bunce wrote: > > On Mon, Nov 26, 2001 at 04:25:16PM +0100, Steffen Goeldner wrote: > > > > On reflection I agree that DBI attributes should be consistently > > fetched by name, not a numeric value. &

Re: DBI: get_info()

Now that more and more drivers support get_info(), it's time to provide some documentation for this method. Steffen *** DBI-1.20.orig/DBI.pmSat Aug 25 01:33:52 2001 --- DBI.pm Sun Dec 16 20:25:13 2001 *** *** 2625,2630 --- 2625,2661 Apache::DBI module for on

DBD::Oracle: get_info()

Attached is a possible implementation for DBD::Oracle. Only a few information types are supported, but it's a beginning. I think, all currently supported information types are stable across most Oracle releases. Other types may depend on a specific version, thus SQL_DBMS_VERSION is a top entry in

DBD::ADO: get_info()

Attached is a possible implementation for DBD::ADO. Only a few information types are supported, but it's a beginning. I'm somewhat unsure about SQL_DRIVER_*, because two layers (DBD::ADO and an ADO Provider) are involved. Steffen *** DBD-ADO-2.4.02/lib/DBD/ADO.pm Thu Dec 13 01:17:30 2001

Re: FK test: Oracle ODBC 8.1.7.5

Steffen Goeldner wrote: > > Attached are some results for the Oracle ODBC Driver 08.01.0704, > generated with MS ODBC Test 03.00.2301 (Odbcte32.exe). > > The last result is wrong: tst.c2 should not appear in the result set. > I created a TAR at Oracle MetaLink. They ac

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > Great stuff, I've applied your patch to the attached copy. Thank you, I like intermediate releases! > I did change the where the ado_consts, myado_types* to attributes of > the database handler, instead of package variable. I was having some > "score" problems. I al

Re: DBD::ADO: column_info

Steffen Goeldner wrote: > > Next, I'll try to find proper TYPE_NAME's. I think about restricting > SchemaProviderTypes by $AdoType, $IsLong, $IsFixed. This gives: > > 1) 0 records, if the provider is buggy > 2) 1 record in most cases > 3) >1 records, e

Re: DBD::ADO: column_info

This is still far from complete, but I made minor improvements: - convert_ado_to_odbc() handles the very special 'adArray' - convert_ado_to_odbc() handles temporal datatypes - column_info() provides a more complete mapping For your demo table, column_info() returns: demo ID 4 Long

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > > Tom, what's your opinion? Can we use the FieldAttributeEnum's or > > should we add %DBCOLUMNFLAGS to DBD::ADO? > > My opinion is to use FieldAttritueEnum. Two reasons: It's supported > in TypeLib, and inherit to ADO. Less problems with changes in the > future. >

Re: DBD::ADO: constants

Thomas A. Lowery wrote: > > Local::DBI::ADO::TypeInfo - ADO TypeInfo > > I'd like to include this with DBD::ADO, except using the package name > DBD::ADO::TypeInfo. This is excellent work and does increase the self > documenting code and clarity. OK? > Yes, of course! Steffen

Re: DBD::ADO: column_info

Steffen Goeldner wrote: > > From the COLUMNS Rowset (adSchemaColumns), we'll need: > > - DATA_TYPE ! > - IS_NULLABLE ? see COLUMN_FLAGS > - COLUMN_FLAGS ! not all flags, but: >- D

Re: DBI: get_info() constants

Tim Bunce wrote: > > You have _way_ too much free time Steffen! Since I'm using perl, DBI, ... > The only things that comes to mind are that there's a specific api > call for require'ing a file that should be used to avoid static's > and threading issues. I used eval_pv() because of it's buil

Re: DBI: get_info() constants

Tim Bunce wrote: > > On Mon, Nov 26, 2001 at 04:25:16PM +0100, Steffen Goeldner wrote: > > > > > else if (htype==DBIt_DB && strnEQ(key, "SQL_", 4)) { > > /* XXX DBIt_ST ? */ > > valuesv = dbih_get_info(h, key, keylen); > &g

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > Steffen, > > So that we're talking apples to apples, I've attached a zip file > that includes an experimental version of DBD::ADO (2.4_01), an > Access 2000 mdb (mytest.mdb) with a table called demo that > includes all the different dat

Re: DBI: get_info() constants

Tim Bunce wrote: > > On Fri, Nov 23, 2001 at 03:16:32PM +0100, Steffen Goeldner wrote: > > Tim Bunce wrote: > > (see <http:[EMAIL PROTECTED]/msg00499.html>) > > > > > > [And I'd ideally like to be able to detect and warn about misspelt > >

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > > > > BTW: It seems, that the statement handle attributes need the > > > > same mapping. > > > > > > So the Provider does not supply any information on how to support > > > data types adVarWChar and adLongVarWChar. > > > > Perhaps ADO char types already support un

Re: DBD::ADO: column_info

Thomas A. Lowery wrote: > > 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 datatyp

DBI: get_info() constants

Tim Bunce wrote: (see ) > > [And I'd ideally like to be able to detect and warn about misspelt > SQL_ attributes. And I'd also like to make it easy to map the names > into their official numbers (to make life easier for drivers, > especially DBD::ODBC). So

DBD::ADO: constants

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

Re: tables() and table_info()

Jason E. Stewart wrote: > > "Steffen Goeldner" <[EMAIL PROTECTED]> writes: > > > Indeed, our first attempt (DBD::Oracle) checked for an array ref: > > > > http:[EMAIL PROTECTED]/msg00091.html > > Reading the thread it's hard to tell w

Re: DBI: get_info(), MS Access test case

Test environment: MS ODBC Test 2.60.0905 MS Access Driver (*.mdb) 4.00.6019 Attached is the (slightly edited) output of 'Get Info All'. Steffen 20 SQL_ACCESSIBLE_PROCEDURES "Y" 19 SQL_ACCESSIBLE_TABLES "Y"

Re: DBI: get_info(), Oracle test case - Oracle ODBC

Test environment: MS ODBC Test 2.60.0905 Oracle ODBC 8.1.7 Attached is the (slightly edited) output of 'Get Info All'. Please note: Some values depend on the server release. However, I couldn't encounter any SQL query activities (in v$sqlarea). Steffen 20 SQL_ACCESSIBLE_PROCEDURES

Re: tables() and table_info()

arguile wrote: > > Side note: > -- > > I might as well raise an issue that's been bothering me about the metadata > function. A lot of the ODBC spec seems to map awfully to Perl. I mean, look > at the table_info() function. > > The value of $type is a comma-separated list of one

DBI: get_info()

Both, SQL/CLI and ODBC define a function 'SQLGetInfo' for obtaining information about the implementation: SQLRETURN SQLGetInfo ( SQLHDBC ConnectionHandle , SQLUSMALLINT InfoType , SQLPOINTERInfoValuePtr , SQLSMALLINT BufferLength , SQLSMALLINT* StringLengthPtr );

Re: DBI: Metadata routines

Tim Bunce wrote: > > > Boy, I'm I going to owe you lots of beer! ;-) > Great! This is my favourite sort: http://www.koestritzer.de/ ;-) > > > > - What should be placed on top of the TODO list? > > get_info That was my fear ;-) > > Of course, to be practical we'd need to start listing th

DBI: Metadata routines

Metadata routines are used to obtain information about - drivers and data sources - the implementation - the catalog The following table shows these routines defined by SQL/CLI, ODBC and DBI: SQL/CLI ODBC DBI -

DBI: table_info() doc patch

The patch corrects a small typo. Further, 2 lines above, the phrase ... one or more then them then ... looks a bit weird to me. Maybe ... one or more of them then ... is better? But I left it to the native english speakers. Steffen *** DBI-1.20.orig/DBI.pmSat Aug 25 01:33:52 200

Re: SQL data type codes

Steffen Goeldner wrote: > > Steffen Goeldner wrote: > > > > Tim Bunce wrote: > > > > > > I'll happily accept a patch that adds the new standard types as well, > > > > Attached. > > > > Sorry, I forgot to patch the documentation .

<    1   2   3   >