Thanks, applied.
Tim.
On Thu, Mar 11, 2004 at 12:14:49PM -0500, Jeff Urlwin wrote:
>
> >
> > A release candidate is available for testing at:
> >
> > http://homepage.eircom.net/~timbunce/DBI-1.42-rc2-20040311.tar.gz
>
> Compile error on Win32, AS perl
what's the "locate" script and why does it find BerkeleyDB.pm
in .../5.6.1/i386-freebsd? What perl binary is it running?
(does "perl -S locate BerkeleyDB.pm" give the same result?)
Tim.
On Thu, Mar 11, 2004 at 09:01:27AM -0800, David Wheeler wrote:
> On Mar 11, 2004, at
T_ERR_* macros
- Recording 'success with info' (incl db messages etc) and 'warnings'
- bind_param() TYPE attribute specification
- bind_col() TYPE attribute specification
Thanks!
Tim.
On Thu, Mar 11, 2004 at 05:45:37AM -0800, Jeff Zucker wrote:
> Tim Bunce wrote:
>
> >Meanwhile, the best workaround for the DBI probably to make t/50dbm.t
> >remove from @INC any dirs which match /\/5\.[0-9.]$/ but which don't
> >also have an arch-specific direc
On Wed, Mar 10, 2004 at 12:38:46PM -0800, David Wheeler wrote:
> On Mar 10, 2004, at 12:33 PM, Tim Bunce wrote:
>
> >What does "perl -V" report?
>
> @INC:
> /usr/local/lib/perl5/5.8.2/i386-freebsd
> /usr/local/lib/perl5/5.8.2
> /usr/local/l
On Wed, Mar 10, 2004 at 10:55:37AM -0800, David Wheeler wrote:
> On Mar 10, 2004, at 10:39 AM, Tim Bunce wrote:
>
> >Any idea why your perl v5.8.2 has .../5.6.1/... in its @INC?
>
> Could it be because site_perl should have pure Perl modules in it, and
> so they should
On Tue, Mar 09, 2004 at 08:22:45AM -0800, David Wheeler wrote:
> On Mar 9, 2004, at 7:16 AM, Tim Bunce wrote:
>
> >A release candidate is available for testing at:
> >
> > http://homepage.eircom.net/~timbunce/DBI-1.42-rc1-20040309.tar.gz
>
> I get failures on
386-freebsd/BerkeleyDB.pm line 970.
t/zz_50dbm_pp..ok
Odd.
Anyone care to discover why there's no error in the first case?
(I've no time to dig.)
Tim.
o consider/try-out the new
- dbvport.h mechanism (see DBI::DBD docs)
- The DBIc_TRACE_LEVEL(imp_xxh) macro
- DBIc_SET_ERR_* macros
- Recording 'success with info' (incl db messages etc) and 'warnings'
- bind_param() TYPE attribute specification
- bind_col() TYPE attribute specification
Thanks!
Tim.
s has already been fixed in 1.42-tobe. Please ignore then!
It's also fixed for the next DBI release. Thanks.
Tim.
h the extra clutter. DBI v2
will use PERL_NO_GET_CONTEXT and drivers will have to do the same.
I'll probably branch off DBI v1 in a week or two.
Anyone needing to use the patch on their own DBI is welcome, of course.
Tim.
ed it'll call OCIPasswordChange(...)
report any error as a warning, then proceed to connect using $pass.
Could you try doing that yourself? It'll mean it gets implemented sooner
if you can.
Thanks.
Tim.
On Fri, Mar 05, 2004 at 11:10:00AM +0300, Goncharova Natalia wrote:
>
>
ORACLE_HOME
> warnings using Instant Client.
Thanks.
I'm currently talking to Oracle about getting the header files
included in the instant client. Then, finally, most DBD::Oracle build
problems should fade away...
(Well, I can dream can't I? :-)
Tim.
All true. I'd only add that dbi-users is the place for such issues.
Tim.
On Fri, Mar 05, 2004 at 10:49:12AM +0100, Jochen Wiedmann wrote:
> Beau E. Cox wrote:
>
> >my $sth = $dbh->prepare("select * from some_table limit ?");
> > OK
> >$sth->execu
pity!
> So it whinges a bit about ORACLE_HOME not being set, but works.
I've checked in a change that should stop those. Could you check it for me?
Tim.
free."
Can someone with more time than me please download this and
take a look.
Naturally I'd like DBD::Oracle to support "Instant Clients".
Tim.
eck in changes to it with a separate commit
(owing to a minor subversion bug). Just cd into lib to commit those
changes then cd into t to commit the tests.
Everyone I've given write access to ./lib/... now also has write
access to ./t
So go ahead and check it in. Thanks!
Tim.
p.s. I'll happ
On Thu, Mar 04, 2004 at 09:46:56AM -0800, Jeff Zucker wrote:
> Jeff Zucker wrote:
> >Tim Bunce wrote:
> >
> >But why not just let the DBD::File subclasser define an f_valid_attrs
> >hash and let DBD::File do it like this (only for lower-cased attribute
> >names
On Thu, Mar 04, 2004 at 08:56:30AM -0800, Jeff Zucker wrote:
> Tim Bunce wrote:
> >On Thu, Mar 04, 2004 at 01:23:32AM -1000, Beau E. Cox wrote:
> >
> >>On Wednesday 03 March 2004 11:50 pm, Beau E. Cox wrote:
> >>
> >>
> >>>Hello folks,
>
On Wed, Mar 03, 2004 at 03:50:14PM +0100, Kristian Nielsen wrote:
> Tim Bunce <[EMAIL PROTECTED]> writes:
>
> > Or, looking at it a different way, does this work:
> >
> > $sth = $dbh->prepare("INSERT INTO mytable VALUES( :foo )");
> > $sth
;\n%s %s\n%s %s\n%s %s\n%s %s\n",
> - 'DBD::DBM' , $dbh->{Driver}->{Version}
> - , 'DBD::File' , $dbh->{Driver}->{file_version}
> - , 'DBI::SQL::Nano' , $dbh->{Driver}->{nano_version}
> - , 'SQL::Statement' , $dbh->{Driver}->{statement_version}
> + 'DBD::DBM' , $dbh->{Driver}->{Version} || 'undef'
> + , 'DBD::File' , $dbh->{Driver}->{file_version} || 'undef'
> + , 'DBI::SQL::Nano' , $dbh->{Driver}->{nano_version} || 'undef'
> + , 'SQL::Statement' , $dbh->{Driver}->{statement_version} || 'undef'
> ;
Thanks, applied.
Tim.
t; Not sure what that means, but I'll try again with the patch inline
> instead of as an attachment.]
Make sure the attachment is "text/plain" MIME type.
> Tim Bunce <[EMAIL PROTECTED]> writes:
>
> > How about this... Don't implement execute_ar
Thanks Beau
Tim.
On Mon, Mar 01, 2004 at 07:52:33AM -1000, Beau E. Cox wrote:
> Hello -
>
> I know that the conversion of DBI to PERL_NO_GET_CONTEXT
> will wait until DBI v2, but I have implemented the change.
> You may view the patch and test results at:
>
> <htt
Fixed, thanks.
Tim.
On Mon, Mar 01, 2004 at 05:00:09PM -0800, Dean Arnold wrote:
> I think I've found a (small) problem in the execute_for_fetch POD (ver. 1.41),
> in the example there's an extraneous $ins->execute()
> (either that, or I still don't understand how thi
[CC'd to dbi-dev]
On Sun, Feb 29, 2004 at 09:56:00PM +0100, Kristian Nielsen wrote:
> Hi Tim,
>
> Tim Bunce <[EMAIL PROTECTED]> writes:
>
> > Where did we get to with this?
>
> > > Ok, I will merge it into the new DBD::Oracle when that is out. It re
r not.
> >
> > I agree!
>
> Here's the patch.
Thanks, applied.
> Note, unfortunately, that I can't seem to test the
> zz_50dbm_pp.t successfully, but I don't think I caused that... ;). Nope. I
> didn't. Svn revert and tests came out the same.
T
On Thu, Feb 26, 2004 at 06:22:48PM -0500, Jeff Urlwin wrote:
> Tim,
>
> Would you mind if DBI held constants, exportable via sql_types for
> SQL_CURSOR_X.
Constants yes, via :sql_types probably not. I'll add more :sql_foo's
This one could be :sql_cursor_types
The DBI
er' topic for tracing
whatever the 'layer' below the driver is.
And an SQLP for client-side sql parser, if there is one being used
(DBI::SQL::Nano or SQL::Statement).
Tim.
above are all targeted a removing
'obscure details' from the 'normal' trace. I think that's one of the
best uses for topics: Let the normal trace levels be less cluttered.
Tim.
p.s. A reminder: a driver should output no trace information at all
at trace levels 1 and 2 (unless a specific topic is enabled).
On Thu, Feb 26, 2004 at 09:42:10AM +0100, H.Merijn Brand wrote:
> On Wed 25 Feb 2004 18:17, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > After initial setup by Rob and Ask at perl.org, and a kickstart
> > from Jeff Urlwin loading the old releases, I'm happy to say that
>
empty email to [EMAIL PROTECTED]
Tim.
Applied, thanks!
Tim.
On Tue, Feb 24, 2004 at 01:05:44PM +0100, Paskamp, Marco wrote:
> Hi,
> using DBI 1.40/1.41 there seems to be a small bug in the macro definition for the
> macro DBD_ATTRIB_DELETE(...)
> The following patch should help.
>
> 493c493
> < hv_
On Tue, Feb 24, 2004 at 09:38:38AM +0100, Steffen Goeldner wrote:
> 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 att
On Mon, Feb 23, 2004 at 10:48:45AM +0100, H.Merijn Brand wrote:
> On Sun 22 Feb 2004 20:29, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > A second release candidate is available for testing at:
> >
> > http://homepage.eircom.net/~timbunce/DBI-1.41-rc2-20040222.tar.gz
>
On Sun, Feb 22, 2004 at 05:04:24PM -1000, Beau E. Cox wrote:
>
> OK. I will test with 5.6.1 later today and let you know the
> results.
> The patch will be ready when you are.
Great. Thanks Beau.
Tim.
ial more_results() method
can be added.
I think DBD::ODBC and DBD::Sybase have this already. DBD::Pg may do.
DBD::mysql is going to need it etc etc. So the DBI needs to support it
so it's done consistently and to make life easier for future driver authors.
I'd appreciate it if all driver authors who have written such code to send
(just) me a copy of the function so I can get an idea what you're all doing.
Thanks.
Tim.
s implementing this scheme in
> perl 5.8.2 - prob. the perl ithreads bug.
>
> So, it was very instructive, and I have patches for what
> I did.
>
> Tim: would you like me to submit the DBI patch? Via svn?
Not yet. After DBI 1.41 is released I was planning to have a
discussion he
On Sun, Feb 22, 2004 at 12:09:13PM -0800, David Wheeler wrote:
> On Feb 22, 2004, at 11:29 AM, Tim Bunce wrote:
>
> >A second release candidate is available for testing at:
> >
> > http://homepage.eircom.net/~timbunce/DBI-1.41-rc2-20040222.tar.gz
>
> All tes
ers would be
appreciated.
I'd also like driver authors to consider/try-out the new
- dbvport.h mechanism (see DBI::DBD docs)
- DBIc_SET_ERR_* macros
- Recording 'success with info' (incl db messages etc) and 'warnings'
- bind_param() TYPE attribute specification
- bind_col() TYPE attribute specification
Thanks!
Tim.
, but we should probably be
> consistent and allow the user to change it with a flag.
I don't think the DBI docs mandate SQL/CLI for foreign_key_info.
It's just pointing out that a driver may return a statement handle
where $sth->{NAME} may have either set of column names.
Tim.
al flag to toggle
> between the two. The global can be set at connect and resides
> at the $dbh level. The local is an extra attrib send to the
> prepare() method, which would override the global method.
Yeap. That would be my preferred approach.
Tim.
DBI code (dbih_get_attr_k()) I'm not sure
> > why it doesn't get into infinite recursion calling FETCH.
> > I'll look into that.]
> >
> > Anyway, try returning &sv_undef. I think it should also warn(...) if
> > DBIc_WARN(imp_xxh) is true.
>
> Ok -- I did this and it still returns a ref to an empty array.
I don't see how it could. Can you find out what's going on?
> Do you want a similar patch for DBD::Oracle ??
Once the ref to an empty array issue is resolved. Thanks.
Tim.
ind any
> conclusion on google. It's been a day of babysitting my three young kids,
> so please excuse me if I missed it ;)
I need to look back to what I said when this came up before. I think there
are some changes I could make so that FETCH could trigger PrintError/RaiseError.
Currently it can't.
Tim.
On Sat, Feb 21, 2004 at 10:04:02AM -0500, Jeff Urlwin wrote:
> Tim,
>
> This patch averts a small warning emitted when running Makefile.PL from the
> current subversion repos. (Hey -- at least someone is using it!!!)
Yeah. Thanks.
> Also, I have a minor request. When you
st, plus waiting
for some utf8 issues to get resolved, hopefully.
Tim.
ent as well. Can we add one
> in to DBI? I was thinking of using a flag to toggle between
> ODBC and SQL/CLI.
I'll add \%attr to all the metadata methods that don't have one.
Tim.
ending the schema name. [Greg Sabino Mullane]
pg_noprefix?
Tim.
On Fri, Feb 20, 2004 at 12:19:31PM +0100, Steffen Goeldner wrote:
> Tim Bunce wrote:
> > Have you tried using the new set_err semantics for warnings DBD::ADO?
>
> DBD::ADO currently uses the err=0 feature:
>
> $DBD::ADO::err = 0 unless $DBD::ADO::errcum & 1 <
On Thu, Feb 19, 2004 at 02:09:16PM +0100, Steffen Goeldner wrote:
> Tim Bunce wrote:
> >
> > I'd also like driver authors to consider/try-out the new
> > [...]
> > - Recording 'success with info' (incl db messages etc) and 'warnings'
I don't think it belongs in the DBI distribution.
Tim.
On Thu, Feb 19, 2004 at 11:49:08AM +0100, Lubomir Host wrote:
> Hi!
>
> I'm working on database plugin for editor vim. I need print data fetched
> from database to stdout. I write method DBI::st::dump_data(). This p
Thanks, applied.
Tim.
On Wed, Feb 18, 2004 at 06:30:56PM -, Andy Hassall wrote:
> >> SQL*Plus can report the version of the Oracle home in a
> >> readily parseable way:
> >>
> >> $ echo DEFINE _SQLPLUS_RELEASE | sqlplus -S /nolog
> >>
On Wed, Feb 18, 2004 at 10:56:23AM +0100, Steffen Goeldner wrote:
> 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
On Wed, Feb 18, 2004 at 10:22:27AM +0100, Steffen Goeldner wrote:
> The attached patch is a resubmission of this one:
>
> <http://www.xray.mpe.mpg.de/mailing-lists/dbi/2003-11/msg00209.html>
Ah, thanks. I'd lost that one. I've also now clarified the docs
about the &#
ing that you'll find that the project is stalled waiting for parrot
and IMCC to have better support for objects and methods.
So, for the timebeing, the best thing to do is offer to help out on the
[EMAIL PROTECTED] mailing list.
Tim.
appreciated.
I'd also like driver authors to consider/try-out the new
- dbvport.h mechanism (see DBI::DBD docs)
- DBIc_SET_ERR_* macros
- Recording 'success with info' (incl db messages etc) and 'warnings'
- bind_param() TYPE attribute specification
- bind_col() TYPE attribute specification
Thanks!
Tim.
ror, PrintError,
> AutoCommit)
> entries from the \%attr and assigning the result to the internal $dbh.
>
> Note this is repeated for each thread.
>
> Any ideas what's amiss here ? Guess I'll try leaving the std. attrs alone and
> assigning them after connect()...
Can you reproduce the error with the latest versions of perl
(including bleadperl)?
Can you reproduce the error with a different driver?
Tim.
hod).
>
> The problem only happens when the main thread
> opens a connection, and then spawns some threads
> that also open connections.
That's because when a new thread is started it clones the
perl interpreter and that includes the installed methods.
Tim.
r
subclassing yet anyway). $h->set_err() is recommended.
You've reminded me to fix all those in the DBI distribution,
which I've just done. Thanks.
> After resolving item (1) above, things now behave as expected,
It's nice when problems are resolved by removing code :)
Tim.
ing the trace level and trace flags.
As a driver authors you should *copy* that file into your distribution
and #include it. Then change your code to use the new macros.
That way you'll be using the new APIs but also backwards compatible
to older versions of the DBI.
Any questions?
Tim.
ecent standards refer to this as COLUMN_SIZE but we stick
with PRECISION for backwards compatibility.)
=cut
> BTW: is there a possible DBI API inconsistency ?
>
> type_info() defines COLUMN_SIZE as the size in bytes;
> but column_info() defines COLUMN_SIZE as size in chars.
type_info() is wrong, it should be chars. Fixed. Thanks.
Tim.
{PRECISION} return the length of
> CHAR/VARCHAR fields as bytes or characters ?
> I see type_info's COLUMN_SIZE attribute is for bytes...
> should I infer the same for PRECISION ?
I'll side-step the question by asking what's the answer for ODBC?
Because whatever it is, that's what it'll be for the DBI.
Tim.
On Tue, Feb 10, 2004 at 11:37:22AM +0530, Waseem Anis wrote:
>Please Ignore.
Please don't send.
you could try using Oracle::OCI.
It gives you access from Perl to almost all of the OCI API.
It also knows how to "grab the Oracle handle pointers" from DBD::Oracle handles
the 'official' (though undocumented) way.
Tim.
do this for me let me know and I'll talk you
through what I'm thinking of.
Tim.
t be talking about what's in it or when it's due
except to say lots and not anytime soon.
Tim.
On Mon, Feb 02, 2004 at 07:03:29PM +0100, H.Merijn Brand wrote:
> On Mon 02 Feb 2004 18:53, Jeff Zucker <[EMAIL PROTECTED]> wrote:
> > Tim Bunce wrote:
> >
> > >It's 2004 and we can't even write VARCHAR(1024). How sad is that?
> > >
> > >
On Mon, Feb 02, 2004 at 10:00:15AM -0500, Sterin, Ilya (I.) wrote:
> I'll set up instructions on a separate link on dbi.perl.org.
>
> I set aside a full day this wednesday to work on the site and get it up to speed.
Great!
Tim
p.s. I've just added this to the CONTRIBUTIN
On Mon, Feb 02, 2004 at 03:13:03PM +0100, H.Merijn Brand wrote:
> On Sun 01 Feb 2004 22:33, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > Which databases cannot accept, and do something reasonable, with a
> > VARCHAR field declaration of 1024 characters?
>
> · Unify does n
On Sun, Feb 01, 2004 at 04:16:44PM -0800, Michael Peppler wrote:
> On Sun, 2004-02-01 at 13:33, Tim Bunce wrote:
> > Which databases cannot accept, and do something reasonable, with a
> > VARCHAR field declaration of 1024 characters?
>
> Sybase < 12.5 will throw an error
ified is greater than 255, the column type is converted
to TEXT."
[Sigh]
> bad - DBD::ODBC:msaccess
No surprise. [Sigh]
Oh well. We're stuck with the yuck. But it does serve as a powerful
illustration of the problems of trying to be portable across databases.
It's 2004 and we can&
[CC'd to dbi-dev]
On Mon, Feb 02, 2004 at 04:28:45AM -0500, Jeff Urlwin wrote:
> Tim,
>
> Can you tell me exactly which commands you used?
If you just want to get a copy to look at or patch you'd just to
svn checkout http://svn.perl.org/modules/dbi/trunk/
That'
up to 255 characters,
but will pass the test above because it'll silently convert VARCHAR(1024)
into a TEXT type column (ie a LONG).
So, back to the original question: Which databases cannot accept,
and do something reasonable, with a VARCHAR field declaration of
1024 characters?
Tim.
p.s.
an
ODBC driver, *not* a Perl DBD. Implementing an ODBC driver would be
pure C work and would then make ODBTP far more accessible as many
unix tools include support for a ODBC driver manager.
Tim.
On Sun, Feb 01, 2004 at 03:10:11PM -0500, Robert Twitty wrote:
> Hi Tim
>
> ODBTP is a sol
On Sun, Feb 01, 2004 at 12:44:24PM +, Tim Bunce wrote:
> The DBI source code is now hosted under Subversion at
> http://svn.perl.org/modules/dbi/
>
> (Many thanks to the unsung heroes at perl.org, especially Robert Spier
> and Ask Bjørn Hansen, for setting this up.)
&
empty email to [EMAIL PROTECTED]
I started the subversion history with DBI-1.38 then DBI-1.39 and
DBI-1.40, each of which has been tagged by copying a snapshot to
http://svn.perl.org/modules/dbi/tags/
Tim.
Robert, did anything come of this?
And/or have you thought about providing an ODBC driver interface
so it could be used via any unix ODBC driver manager?
(And thereby DBD::ODBC for Perl.)
Tim.
On Tue, Dec 02, 2003 at 10:27:09AM -0500, Robert Twitty wrote:
> Hello
>
> I created an op
Did anything come of this?
Has anyone tried using DBD::ODBC with the mdbtools ODBC driver to
access an Access .mdb file[*](possibly networked via Samba etc etc)?
Tim.
[*] Of course it's really a 'Jet' database engine file, and Jet is
also used in MS Money, Project, IIS, and Ex
On Fri, Jan 30, 2004 at 02:45:00PM -0800, David Wheeler wrote:
> On Jan 30, 2004, at 2:15 PM, Tim Bunce wrote:
>
> >If you want to be sent email whenever the DBI source code is changed,
> >send an email to [EMAIL PROTECTED] in order to subscribe
> >to the dbi-changes mail
Thanks, applied.
Tim.
On Sat, Jan 31, 2004 at 12:14:36AM -, Andy Hassall wrote:
> > Added $dbh->{ora_parse_error_offset} attribute
>
> Attached: some POD for the attribute above (I should have included this with
> the patch for the attribute), and also for the reauthent
On Fri, Jan 30, 2004 at 12:27:02PM -0700, jim cromie wrote:
> Tim Bunce wrote:
>
> >On Fri, Jan 30, 2004 at 03:00:37AM -0700, jim cromie wrote:
> >
> >>This sounds like it could plug into the trace mechanism, either
> >>increasing its
> >>leve
If you want to be sent email whenever the DBI source code is changed,
send an email to [EMAIL PROTECTED] in order to subscribe
to the dbi-changes mailing list.
Tim.
Thanks applied.
Tim.
On Fri, Jan 30, 2004 at 03:09:42PM -, Avis, Ed wrote:
> This patch stops DBI printing the connection password in an error
> message.
>
> diff -ru DBI-1.40/DBI.pm DBI-1.40-new/DBI.pm
> --- DBI-1.40/DBI.pm 2004-01-08 14:03:57.0 +
> +++ D
; "OCIXMLTypePtr".
Doing the equivalent of m/^OCI(\w+)Ptr$/ and then calling OCITypeByName
with $1 uppercased might take us (or someone) a step further.
> Also note that my code can't handle downloading of XMLType objects yet.
I'll trust that some kind soul with an itch will send a patch :-)
Thanks again Hendrik.
Tim.
> wouldn't publish under normal circumstances. :) I just hope it might me
> useful to someone.
It will. I'll add it in and let others polish it :)
> Well then, time to say goodbye
> thanks to Tim and everyone who contributed to dbi for a great piece of
> software
Thanks H
elp unravel anomalous behavior by automatically putting your fovea
> on it.
I'm not quite sure what you're asking for there.
Tim.
to set_err for compiled drivers.
One to take char* values and one for SV*.
I'm interested to know if people (especially driver authors) think this
mechanism is viable for recording/returning whatever kinds of 'warnings'
and 'success_with_info' your database supports.
On Wed, Jan 28, 2004 at 10:43:57PM +0100, Elizabeth Mattijsen wrote:
> At 00:29 + 1/27/04, Tim Bunce wrote:
> >On Sun, Jan 25, 2004 at 11:14:45PM +, Tim Bunce wrote:
> > > Here's a draft of an announcement about the Parrot DBDI project.
> >Stunned silence?
On Wed, Jan 28, 2004 at 10:41:53PM +0100, Henrik Tougaard wrote:
> Tim Bunce skrev:
>
> > Questions
> >
> >
> > On Sun, Jan 25, 2004 at 11:14:45PM +, Tim Bunce wrote:
> >> Here's a draft of an announcement about the Parrot DBDI project.
> >
On Sun, Jan 25, 2004 at 11:14:45PM +, Tim Bunce wrote:
> Here's a draft of an announcement about the Parrot DBDI project.
Stunned silence?
Tim.
alarm(0) both in and out of the eval
> block, are there any unforseen consequences to setting alarm(0) a
> couple of times in a row?
No.
Tim
r to make it explicit. I guess a comment that it
autovivifies would have sufficed. Ho hum.
Tim.
On Mon, Jan 26, 2004 at 02:21:33PM -, Avis, Ed wrote:
> Tim Bunce <[EMAIL PROTECTED]> wrote:
>
> >Actualy I did this instead, as it seems more correct:
> >
> >@@ -1720,5 +1721,6 @@
> > sub execute_for_fetch {
> >
On Mon, Jan 26, 2004 at 01:18:19PM +, Tim Bunce wrote:
> Thanks, applied.
>
> Tim.
>
> On Mon, Jan 26, 2004 at 10:18:03AM -, Avis, Ed wrote:
> > This patch to DBI-1.40 fixes an error
> >
> > Can't use an undefined value as an ARRAY reference a
Thanks, applied.
Tim.
On Mon, Jan 26, 2004 at 10:18:03AM -, Avis, Ed wrote:
> This patch to DBI-1.40 fixes an error
>
> Can't use an undefined value as an ARRAY reference at DBI.pm line 1735
>
> when using execute_array() with zero values for a bind parameter. It
>
On Mon, Jan 26, 2004 at 09:42:36AM +, Sean Kelly wrote:
> Quoting Tim Bunce <[EMAIL PROTECTED]>:
>
> > Available now for testing:
> >
> > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc3-20040123.tar.gz
> >
> > Hopefully this fixes
Here's a draft of an announcement about the Parrot DBDI project.
What's that? I hear you ask. Well, read on...
I'd appreciate any feedback you may have, especially any more
questions that I should address.
Tim.
---
=head1 Parrot DBDI Project: a Database Driver Interface for
Please send emails like this to [EMAIL PROTECTED] - I've CC'd this reply there.
On Sun, Jan 25, 2004 at 11:54:15AM -0500, Michael Hoy wrote:
>
> Hi Tim,
>
> I'm the maintainer for DBD::DB2 and currently working on an issue that I'm
> hoping you she
expected 'trailing' but got 'trailing ' for VARCHAR2
>t/ph_typeFAILED test 12
>Failed 1/19 tests, 94.74% okay
It's still unknown if that's an Oracle bug in 9.2.x or a spec change.
SOmeone was going to open a TAR with Oracle to find out. I don't
know if that happened.
Tim.
se UV's to IV's
but upgrading your perl to at least 5.6.1 is strongly recommended.
Tim.
Available now for testing:
http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc3-20040123.tar.gz
Hopefully this fixes (more of) the build problems.
I'd appreciate it if you could give this a whirl and report any
problems (in detail) or any successes!
Thank you.
Tim.
1201 - 1300 of 1996 matches
Mail list logo
