This message is a follow-up to the one of a few hours ago titled
"RFC: renaming SQL::Routine out of SQL". The context of the old RFC
has changed.
The one on-topic reply I got so far, from David Wheeler (which
suggested renaming "the SQL::Routine language" to "Rosetta"),
inspired me to take a
This RFC is an early probe, and is only being sent to 2 discussion
lists for now, dbi-users and poop-group. If necessary, I may derive
a better version later for wider dissemination, based on your
feedback.
In the course of my rewrite of the Rosetta database access framework
(started on Octo
- Original Message -
From: "Ronald J Kimball" <[EMAIL PROTECTED]>
To: "'Jonathan Mangin'" <[EMAIL PROTECTED]>;
Sent: Friday, January 06, 2006 12:35 PM
Subject: RE: Can't use mysql's curdate() as bind variable?
> Jonathan Mangin [mailto:[EMAIL PROTECTED] wrote:
> >
> > curdate() works
I am missing something here (probably a few brain cells),
how do I set up the dsn for DBD::AnyData (fixed format)
when using dbish?
Thanks,
STH
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Scott T. Hildreth wrote:
I am missing something here (probably a few brain cells),
how do I set up the dsn for DBD::AnyData (fixed format)
when using dbish?
Well, it's rather messy because dbish's execution of perl is a bit
messy. But it works fine. Try this:
1)
On Fri, Jan 06, 2006 at 09:07:42AM -0800, Gerald Gallagher wrote:
> Trying to compile DBI 1.50 on Solaris 8 using Sun WorkShop 6. The
> "40profile" test fails because dbi_profile_merge is returning way too many
> decimal places. Can I assume that this is due to my Perl 5.8.4 compiled with
> US
On Fri, Jan 06, 2006 at 01:19:11PM -, Martin J. Evans wrote:
>
> This seems to be due to finish in the driver being called twice. I'm
> not overly familiar with DBD::mysql but commenting out the finish call
> (in dbd_st_fetch) below makes the problem go away:
>
> if ((rc= mysql_stmt_fetc
Jonathan Mangin [mailto:[EMAIL PROTECTED] wrote:
>
> curdate() works if $edate is embedded directly in my
> sql statement, but not as a bind variable. $bdate works
> fine.
>
> my $bdate = $q->param('bdate') || '%';
> my $edate = $q->param('edate') || 'curdate()';
>
> my $sql = "create table $tem
curdate() is a function, not a data value.
On 1/6/06 10:18, "Jonathan Mangin" <[EMAIL PROTECTED]> wrote:
> curdate() works if $edate is embedded directly in my
> sql statement, but not as a bind variable. $bdate works
> fine.
>
> my $bdate = $q->param('bdate') || '%';
> my $edate = $q->param('e
Trying to compile DBI 1.50 on Solaris 8 using Sun WorkShop 6. The "40profile"
test fails because dbi_profile_merge is returning way too many decimal places.
Can I assume that this is due to my Perl 5.8.4 compiled with USE_LONG_DOUBLE ?
I don't have the option to recompile Perl... Anyone have
> Now I am trying to install DBD::Oracle 1.16 version to Oracle
> 10.2.0.1.0_64 db server.
> Since I am using Perl 32 bit version 5.61 and I do not have
> permissions to upgrade it to 64 bit,
> IS THERE A WORKAROUND to get this installed with 32 bit perl?
You can't use 64-bit Oracle libraries wi
curdate() works if $edate is embedded directly in my
sql statement, but not as a bind variable. $bdate works
fine.
my $bdate = $q->param('bdate') || '%';
my $edate = $q->param('edate') || 'curdate()';
my $sql = "create table $temp_tbl
(date date,
uid varchar(14))
Hi,
I colleague of mine has been briefly using DBD::mysql and was getting
a lot of "FREE ERROR BIND!" messages appearing on stderr. I was asked
to take a look and I've reproduced this with the following code
running against DBD::mysql 3.0002_4:
use DBI;
# DBI 1.50
# perl, v5.8.7 built for i686-li
Hi there,
Has anyone seen this message before?
install_driver(Oracle) failed: DBD::Oracle object version 1.16 does not
match bootstrap parameter 1.06 at C:/Perl/lib/DynaLoader.pm line 253.
If so do you know how to fix it? I am running windows 2000 with an
Oracle 9i client and ActivePerl 5.8.
14 matches
Mail list logo
