Tim Bunce wrote:
I'd be interested in the COLUMN_DEF values for other databases and DBDs
but it's not urgent. Hopefully others can fill in the gaps.
(Oracle and mysql are two big missing databases at the moment.).
DBD::Oracle (s/current_user/user)
undef, 'TST', 'MARTIN', 'A', '3', 'NUMBER',
Martin Evans wrote:
[...]
This works. Out of interest, the set_err docs also say setting err to
is an informational state. Under what conditions do/can you see those?
If it helps, here is the thread where this topic evolved:
Cosimo Streppone wrote:
Hi all,
I found a strange problem in DBI::type_info().
I don't know much of DBI internals. Only found that sometimes,
the 'type_info_all' structure returned by the driver is
mangled by some shift() that happens in DBI::type_info().
This happens only for DBD::Informix
John Scoles wrote:
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.19-RC1.zip
Changes in DBD-Oracle 1.19 (scn rev 7879)
Fixed execute_array to comply with DBI standard from Martin J. Evans, Xho
Jingleheimerschmidt and others
Fixed execute_array so it will not throw a Perl
Tim Bunce wrote:
http://www.data-plan.com/public/DBD-Oracle-1.17-RC2.tar.gz
On Oracle8:
# failed test 34 at line 120. ORA-00904: invalid column name
(DBD ERROR: error possibly near * indicator at char 15 in '
select *to_dsinterval(:p1) from dual
')
not ok 34
Patch
Tim Bunce wrote:
Thanks, applied.
Tim.
Fine, and I suppose you don't argue against a PAUSE registration?
Steffen
I'd like to register 'monetdb_' as prefix for DBD::monetdb,
the DBI driver for MonetDB:
http://monetdb.cwi.nl
Steffen
Index: DBI.pm
===
--- DBI.pm (revision 1457)
+++ DBI.pm (working copy)
@@ -308,6 +308,7 @@
ing_
H.Merijn Brand wrote:
Anyway to make this work *portable* ?
e.g. Unify normalizes everything to as it was entered :)
in Oracle all other operations work quite ok when using lower case
table/column names: select, drop, create, ...
The behavior for identifiers (quoted or not) is described by
H.Merijn Brand wrote:
[...]
is there a way to make it comply to the documented fields in DBI?
FWIW Unify does not support field renaming/aliasing in the select statement,
so the only alternative I can think of is a view, which would alter the
database, and that is not something to aim for.
Tim Bunce wrote:
On the occasion of the 1st anniversary - where did the time go?
When a batch is first executed the statement handle appears exactly
as if the batch only contained the first sub-statement.
The only exception is that the $sth-{NUM_OF_PARAMS} attribute
equals the total number
Attached is a small benchmark script. The test platform is:
CPU: x86 1994 MHz
RAM: 500 MB
OS : Win2k
I redirected the output to circumvent the slow console:
set ADO_DSN=Provider=MSDAORA;Data Source=prod;User ID=***;Password=***
perl Benchmark.pl Benchmark.out
The output looks like:
Tim Bunce wrote:
On Wed, Mar 16, 2005 at 01:13:00AM +0100, Steffen Goeldner wrote:
Currently, a result set has to be completely materialized
on the client before it can be fetched via DBD::Sponge:
Large result sets may exhaust available memory. We could
reduce memory usage at the cost of CPU time
Currently, a result set has to be completely materialized
on the client before it can be fetched via DBD::Sponge:
my $cursor = ...
my $rows = [];
while ( !$cursor-eof ) {
my $row = [ map { $cursor-fields-...
$cursor-next;
push @$rows, $row;
}
$cursor-close;
Looks like t/11fetch.t should return a true value.
Patch attached.
Steffen
Index: t/11fetch.t
===
--- t/11fetch.t (revision 929)
+++ t/11fetch.t (working copy)
@@ -103,5 +103,6 @@
Benchmark::timethis(10, sub { go([EMAIL
FTR: ADO supports nested transactions:
http://msdn.microsoft.com/library/en-us/ado270/htm/mdmthbegintrans.asp?frame=no
The level of nesting may be limited, e.g. Access and Foxpro
support 5 levels, Oracle and SQL Server only 1.
With some bookkeeping, it should be possible to emulate
savepoints
A DBI driver should pass the following tests:
my @ti = $dbh-type_info;
ok( @ti,'type_info');
my $tia = $dbh-type_info_all;
is( ref $tia,'ARRAY','type_info_all');
my $idx = shift @$tia;
is( ref $idx,'HASH','index hash');
However, the last test fails with an implementation of
Jeff Urlwin wrote:
Thanks. Applied.
And now you can try:
make distcheck
make manifest
Steffen
Jeff Urlwin wrote:
That's probably the best thing, but there are probably more places... After reviewing the
code, I think I don't like the duplication of the henv -- but the short term patch is
whenever you see a SQLFreeEnv, also set the imp_dbh-henv to SQL_NULL_ENV. Sorry I
haven't looked at
Hi Jeff,
attached is a small patch for MANIFEST.SKIP to ignore
svn administrative files.
Steffen
Index: MANIFEST.SKIP
===
--- MANIFEST.SKIP (revision 859)
+++ MANIFEST.SKIP (working copy)
@@ -1,4 +1,5 @@
\bRCS\b
+\.svn\b
Steffen Goeldner wrote:
O.k., attached. Looks like SQLError receives a freed
SQL_HANDLE_ENV.
Not sure, but I think I fixed the problem.
In dbd_db_login6, I found:
imp_dbh-henv = imp_drh-henv; /* needed for dbd_error */
In dbd_db_disconnect, I found:
imp_drh-henv = SQL_NULL_HENV;
and added
Martin J. Evans wrote:
Caught a SIGSEGV at C:/opt/perl/site/lib/DBD/ODBC.pm line 208
That is the tables call in the ping method.
The only time you only have an environment handle
dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/21631648
is when not connected to the DSN. The driver manager is supposed to
Hi Jeff,
I have the following test script:
use sigtrap;
use DBI();
use Test::More tests = 5;
my $dbh = DBI-connect or die $DBI::errstr;
ok( $dbh-{$_}, $_) for 'Active';
ok( $dbh- $_ , $_) for 'ping';
ok( $dbh- $_ , $_) for 'disconnect';
ok(!$dbh-{$_}, $_) for 'Active';
ok(!$dbh-
Tim Bunce wrote:
Actually it's only the first letter that matters (so foo_Bar is okay,
if you like that kind of thing :)
I've changed the text to read:
: Note the prefix Idrv_ in the attribute names: it is required that
: all your private attributes use a lowercase prefix unique to your driver.
:
Tim Bunce wrote:
I've added this:
[...]
Comments, or patches against subversion, most welcome.
Fixed this daVinci bug:
- my ($drh, $dbname, $user, $auth, $attr) = @_;
+ my ($drh, $dr_dsn, $user, $auth, $attr) = @_;
as well as a few typos and the like.
Steffen
Index: lib/DBI/DBD.pm
DBI 1.31 suggests that lexically scoped variables should
be passed to _new_dbh():
http://search.cpan.org/~timb/DBI/Changes#Changes_in_DBI_1.31,_29th_November_2002
DBI 1.33 suggests that drivers should no longer pass these
variables to _new_drh() or _new_dbh():
Tim Bunce wrote:
On Mon, Nov 08, 2004 at 10:14:52AM +0100, Steffen Goeldner wrote:
[...]
Attached is a small patch for DBI::DBD::Metadata. $VERSION is
a lexical (why?), thus I dropped the package names.
I added a special handler for the SQL_DRIVER_NAME case, because
the file name of the ODBC
] (previously [EMAIL PROTECTED]),
Jochen Wiedmann [EMAIL PROTECTED],
-Steffen Goeldner [EMAIL PROTECTED],
+Steffen Goeldner [EMAIL PROTECTED],
and Tim Bunce [EMAIL PROTECTED].
=cut
Tim Bunce wrote:
ON Thu, Oct 21, 2004 at 10:41:28AM +0100, Tim Bunce wrote:
On Thu, Oct 21, 2004 at 07:52:42AM +0200, Honza Pazdziora wrote:
t/25plsql is now clean. The perl -Mblib yields
Can't select from function (ORA-06553: PLS-561: character set mismatch on value for
parameter 'ARG2'
Tim Bunce wrote:
Yes, another release candidate!
Perl 5.6.1, Win2k, Borland 5.5,
Oracle Client 8.1.7.4.15,
Oracle Server 8.1.7.2.1
Using C:/temp/DBD-Oracle-1.16-8/blib
t\01baseok
t\10general.ok
t\15nls.ok
t\20select..ok
Tim Bunce wrote:
On Fri, Oct 01, 2004 at 01:46:45PM +0200, Steffen Goeldner wrote:
Tim Bunce wrote:
I can live with assuming support for ANSI C style prototypes
since we already effectively require perl 5.6 and that requires ANSI C.
O.k., attached are the KR = ANSI patches for dbdimp.c and oci8.c
Tim Bunce wrote:
I can live with assuming support for ANSI C style prototypes
since we already effectively require perl 5.6 and that requires ANSI C.
O.k., attached are the KR = ANSI patches for dbdimp.c and oci8.c.
Steffen
--- dbdimp.orig Thu Sep 30 14:26:04 2004
+++ dbdimp.cThu Sep 30
Tim Bunce wrote:
On Wed, Sep 22, 2004 at 03:52:09PM +0200, Steffen Goeldner wrote:
Compiling DBD::Oracle with Borland C++ 5.5, I have a bunch of warnings:
[...]
1. ignore the warnings :-(
2. suppress the warnings (-w-8065)
3. Force __STDC__=1
4. Force C++ compile (-P):
5. Remove the #if/#else
Compiling DBD::Oracle with Borland C++ 5.5, I have a bunch of warnings:
Warning W8065 ...: Call to function 'OCI...' with no prototype in function
because oci.h includes the KR headers:
#if defined(__STDC__) || defined(__cplusplus)
#include ociapr.h
#include ociap.h
#else
#include
Tim Bunce wrote:
On Thu, Jul 15, 2004 at 10:35:14AM +0200, Steffen Goeldner wrote:
Tim Bunce wrote:
Warning W8075 dbdimp.c 82: Suspicious pointer conversion in function
GetEnvOrRegKey
Fixed.
I'm still a bit nervous about returning this pointer to a locally declared
buffer
Tim Bunce wrote:
and now [drum roll please...]
http://homepage.eircom.net/~timbunce/DBD-Oracle-1.16-rc3-20040714.tar.gz
Makefile.PL:
Using DBI 1.43 (for perl 5.006001 on MSWin32-x86-multi-thread) installed in
C:/opt/perl/site/lib/auto/DBI
Configuring DBD::Oracle ...
Tim Bunce wrote:
A release candidate of DBD::Oracle 1.16 is available for testing at:
http://homepage.eircom.net/~timbunce/DBD-Oracle-1.16-rc1-20040713.tar.gz
I wonder if only Borland is that nitpicking:
Error E2140 dbdimp.c 72: Declaration is not allowed here in function GetEnvOrRegKey
Tim Bunce wrote:
A release candidate for DBI 1.43 is available for testing at:
http://homepage.eircom.net/~timbunce/DBI-1.43-rc1-20040628.tar.gz
Looks good for Perl 5.6.1, MSWin32, Borland 5.5:
t\01basicsok
6/109 skipped: various reasons
t\02dbidrvok
Paul Johnson wrote:
Hmmm. That's strange. I suppose $^O is still MSWin32 under Borland
and NT 4?
Yes:
Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
...
But I see you use Test and
Paul Johnson wrote:
That's odd. I would have expected at least three skipped messages, or
did not just not send them?
I sent the complete output.
Urgh. That probably indicates a crash while Devel::Cover is trying to
collect the last of the data. Is is possible for you to test under
Hi Paul,
just compiled Devel-Cover-0.43 with BC++ 5.5, perl 5.6.1, WinNT 4.0 -
looks good:
Using C:/temp/Devel-Cover-0.43/blib
t\aaliasok
t\aalias1...ok
t\abranch_return_subok
t\acond_and.ok
t\acond_branch..ok
Hi Paul,
compiling/linking Devel-Cover-0.41 with Borland C++ 5.5 gives:
Error: Unresolved external '_get_elapsed'
because gettimeofday is missing.
Would it be possible that Devel::Cover reuses the
Time::HiRes implementation?
Steffen
Tim Bunce wrote:
A second release candidate is available for testing at:
http://homepage.eircom.net/~timbunce/DBI-1.41-rc2-20040222.tar.gz
Sorry, I'm latish. The attached patch corrects a few minor typos.
Furthermore, my Borland compiler reports a warning:
Warning W8019 DBI.xs 1166:
Tim Bunce wrote:
[...]
Well spotted. I can replicate that with this change to the tests:
--- t/08keeperr.t (revision 56)
+++ t/08keeperr.t (working copy)
@@ -88,7 +88,7 @@
is($warn, 0);
is(@handlewarn, 1 0 0);
-$dbh-set_err(0, (got warn), AA001);
+$dbh-set_err(0,
The attached patch is a resubmission of this one:
http://www.xray.mpe.mpg.de/mailing-lists/dbi/2003-11/msg00209.html
Steffen--- DBI.origTue Feb 17 13:18:08 2004
+++ DBI.pm Wed Feb 17 22:42:04 2004
@@ -4193,11 +4193,10 @@
LOCAL_TYPE_NAME = 12,
MINIMUM_SCALE = 13,
Tim Bunce wrote:
On Tue, Feb 10, 2004 at 03:53:16PM -0800, Dean Arnold wrote:
I don't think ODBC provides any clear guidance.
It defines 2 distinct descriptor elements:
COLUMN_SIZE: the size in bytes
DISPLAY_SIZE: the size in characters
And PRECISION is only defined wrt numerics;
Jan Dubois wrote:
VT_DATE values used to be returned as strings, but that doesn't give
you any control over how the date is formatted.
I would say the user has - although limited - control with the
global LCID, right?
A long time ago I
changed Win32::OLE to return them as VARIANTs. If
Tim Bunce wrote:
The RaiseError/PrintError/HandleError mechanism only applies at the
point where the DBI is abount to return control to the application.
It isn't triggered by a nested calls (where select*_* calls prepare())
I was planning to implement HandleWarn the same way but
I've
Henrik Tougaard wrote:
Better support for transactions. At some point
I predict that the RDBMS vendors will come up
with transaction handles, and we need somewhere
to hold them - I foresee several concurrent
transactions on the same database handle.
Not to mention nested transactions (or
Tim Bunce wrote:
join \n, ...
Very old (pre perl5!) versions of the DBI spec (or DBPerl as it then was)
mentioned that specifically. I'll add it to the DBI docs.
Indeed, that's what actually happens (for $errstr). But $err is
another story (and don't ask for $state).
Imagine that my
Tim Bunce wrote:
My current plan is to add a $h-{HandleEvent} = sub { ... }
hook that can be used for SUCCESS_WITH_INFO and other events the
driver may want to communicate back to an application.
Meanwhile I suggest that you add a $h-{ado_event} = sub { ... }
and and use that however you
I need an advice on how to deal with SUCCESS_WITH_INFO
from a DBD writers point of view.
If ADO places an error into it's error collection,
this error may be one of 4 kinds (oledberr.h):
00 - Success
01 - Informational
10 - Warning
11 - Error
A good example for the first case is given
Steffen Goeldner wrote:
Tim Bunce wrote:
http://homepage.eircom.net/~timbunce/DBI-1.40-rc1-20040107.tar.gz
I'd appreciate some testing on a variety of platforms, perls and drivers.
For my Perl 5.6.1, MSWin32, Borland 5.5., 03handle.t failed:
Commenting out line 91 (print Dumper
Rerunning this test
http://www.xray.mpe.mpg.de/mailing-lists/dbi/2001-03/msg00626.html
against an Oracle 9.2.0.4 results in
TYPEPRECSCALE NAME
3 38 0 CINTEGER
8 0 0 CNUMBER
3 38 0 CNUMBER_38_0
3 11 2 CNUMBER_11_2
3
The attached patch removes a doubled NUM_PREC_RADIX entry from
the index hash (and adjusts the following indexes).
BTW: These sentences sound somewhat contradicting:
The index values shown above (e.g., NULLABLE = 6) are for
illustration only. Drivers may define the fields with a
different
Hi Tim,
the attached patch adds 'Carp::' to all unqualified
calls to carp() and croak().
You'll get the error message above with something like
perl -MDBI -e 'DBI-connect()-primary_key($c,$s,$t)'
Steffen*** DBI.origFri Aug 22 23:25:40 2003
--- DBI.pm Mon Nov 03 16:14:28 2003
Tim Bunce wrote:
On Fri, Oct 24, 2003 at 11:00:55AM +0200, Steffen Goeldner wrote:
Is there any value in returning a value (pun intended)
from STORE? E.g.:
sub STORE {
...
return 1;
For dbd_db_STORE_attrib(), DBI::DBD states:
The return value is TRUE if you have
Is there any value in returning a value (pun intended)
from STORE? E.g.:
sub STORE {
...
return 1;
For dbd_db_STORE_attrib(), DBI::DBD states:
The return value is TRUE if you have handled the
attribute or FALSE otherwise.
Does the same rule apply to STORE()? If so, where
is the
H.Merijn Brand wrote:
On Fri 24 Oct 2003 11:00, Steffen Goeldner [EMAIL PROTECTED] wrote:
Is there any value in returning a value (pun intended)
from STORE? E.g.:
sub STORE {
...
return 1;
For dbd_db_STORE_attrib(), DBI::DBD states:
The return value is TRUE
Tim Bunce wrote:
[...]
Yes, it's a bug. Try this:
--- DBI.xs 2003/08/21 22:34:45 11.32
+++ DBI.xs 2003/10/10 15:23:34
@@ -2354,10 +2354,10 @@
if (debug) {
SAVEI32(DBIS-debug); /* fall back to orig value later */
+ DBIS-debug = debug;
Tim Bunce wrote:
On Wed, Oct 08, 2003 at 09:23:25AM +0200, Steffen Goeldner wrote:
What's the expected output of the attached script?
Something hopefully useful. That's about all that's guaranteed.
Why do you ask?
As my replies show, something changed between 1.35 and 1.36:
traces
What's the expected output of the attached script?
Steffen
trace.pl
Description: Perl program
DBI 1.38-nothread dispatch trace level set to 9
trace_msg DISPATCH (DBI::db=HASH(0x815cdb4) rc1/1 @3 g0 ima5 pid#12698) at
../trace.pl line 8
- trace_msg in DBD::_::common for DBD::Sponge::db
(DBI::db=HASH(0x815cdb4)~0x8217e78 '= 9 =' 9)
= 9 =- trace_msg= 1 at ../trace.pl line
...
DBI 1.36-nothread dispatch trace level set to 7
DBI 1.36-nothread dispatch trace level set to 6
DBI 1.36-nothread dispatch trace level set to 5
DBI 1.36-nothread dispatch trace level set to 4
DBI 1.36-nothread dispatch trace level set to 3
DBI 1.36-nothread dispatch
Tim Bunce wrote:
On Thu, Sep 25, 2003 at 12:39:05PM +0200, Steffen Goeldner wrote:
Steffen Goeldner wrote:
[...]
I try to find those symbols and the library ...
Thanks to Andy Hassall, I found the symbols in orasql8.dll.
I did not install Pro*C and have a $ORACLE_HOME
Tim Bunce wrote:
Is it an alpha or a beta? Who knows? Probably more alpha than beta
but it it what it is and you're welcome to hit on it.
Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7
dmake test:
t\base...ok
t\cursor.ok
t\generalok
t\long...ok 53/372# failed test 60 at line
Steffen Goeldner wrote:
Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7
[...]
error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR:
OCILobWriteAppend)
Metalink lists such an error as Bug #886191, fixed
in 8.1.7. Hmmm.
Steffen
All tests successful, 9 tests skipped.
Files=34, Tests=1215, 160 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
perl -Mblib -MDBI -e DBI-installed_versions
Using C:/temp/DBI-1.38-RC2/blib
Perl: 5.006001(MSWin32-x86-multi-thread)
OS : MSWin32 (4.0)
DBI
Steffen Goeldner wrote:
[...]
I'm not sure if we need use_ok('DBD::ADO') in all cases.
Thus, the BEGIN {} block could be dropped.
Now I'm sure ;-)
Steffendiff -u t-orig/09null.t t/09null.t
--- t-orig/09null.t Fri Aug 22 00:37:46 2003
+++ t/09null.t Fri Aug 22 11:24:32 2003
@@ -14,8
Hi Thomas,
attached is my current OpenSchema script.
It uses DBD::ADO::TypeInfo to list the SchemaEnum's.
Steffen
OpenSchema.pl
Description: Perl program
Hi Thomas,
here is a script that lists all OLE DB Provider.
Yes, it scans the complete CLSID tree of the registry.
I doubt there is a better way, because my harddrive
sounds similar if I open a .udl file.
Steffen
Provider.pl
Description: Perl program
Thomas A. Lowery wrote:
DBD::ADO Release 2.7 is available from http://stlowery.net/DBD-ADO-2.7.tar.gz
...
t\09null..You tried to run a test without a plan! Gotta have a plan.
t\11curs..You tried to run a test without a plan! Gotta have a plan.
t\15func..You tried to run a test
Tim Bunce wrote:
[...]
If all is well please reply to the list with a short message giving
the output of:
perl -MDBI -e 'DBI-installed_versions'
Perl: 5.006001
OS : MSWin32
DBI : 1.38
DBD::Sponge : 11.09
DBD::Oracle : 1.14
Hi Thomas,
attached is a small patch to provide correct types
in metadata result sets.
Steffen*** ADO.origSat Nov 09 21:08:44 2002
--- ADO.pm Sun Aug 17 22:45:38 2003
***
*** 1141,1148
$conn-{CursorLocation} = $tmpCursorLocation;
While installing e.g. DBD-Oracle-1.14, dmake aborts with:
dmake.exe: Error -- Multiply defined recipe for target C
Dmake doesn't like what the current DBI::DBD::dbd_postamble generates:
# --- MakeMaker postamble section:
# --- This section was generated by DBI::DBD::dbd_postamble()
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 header
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
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 encountered
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/*
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 defines the
Tim Bunce wrote:
[...]
Note that DATETIME_SUB is misspelled with
an SQL_ prefix in the docs. That's wrong. Fixed now.
Really?
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqlgettypeinfo.asp?frame=false
[...]
2. What does the DATA_TYPE field contain when this field contains
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:
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
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 'dmake' with a '$(NOOP)' (see attached patch).
It's
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();
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
***
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
***
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 of schemas, e.g.:
Probably. Especially if Oracle's own ODBC driver
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_SCHEM
?
Yesp, looks like it.
Done (see attachement).
Should I add 'PUBLIC
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' nevertheless?
It may be useful for some generic
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 -
undef for the PUBLIC pseudo-schema
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/odbcpattern_value_arguments.asp
| Passing
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 Cundef to an optional argument does not constrain the search for
+ that argument
+ Some arguments in the catalog functions accept Bsearch patterns (strings
+ containing '_' and/or '%'), e.g. the C$table argument of Ccolumn_info().
Running some tests with 'pattern value arguments',
I encountered missing ESCAPE characters in the
implementation of the DBD::Oracle catalog
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 the
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 identifier are
Currently, long get_info() return values (eg 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-038-orig/dbdimpc Tue Feb 12 19:11:56 2002
--- dbdimpcMon Mar 04
[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 dynamically and
reallocates it if needed
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, since you need both to be =8 to be able to use the
types in typical
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
http:[EMAIL PROTECTED]/msg00359.html
where I could set SQL_ATTR_ODBC_VERSION.
Now it's possible to do it with DBD::ODBC
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
1 - 100 of 144 matches
Mail list logo
