Hello again - thanks for the speedy answers (and for DBI, more to the point)
. Please find below some more detail on this:
# Misc info ==
Perl 5.8.0
DBD/mysql.pm version 2.1020
DBI.pm version 1.32
# code ===
$dbh->trace(2, "./tracefile");
$qst = $dbh->
On Mon, 23 Jun 2003, Tim Bunce wrote:
> Well that puts it firmly into the realm of a DBD::mysql or mysql
> client library problem. Check your mysql command works okay,
> recompile DBD::mysql, etc etc.
OK, mysql checks out OK, so I'll have to grab check out the DBD::mysql
option.
> > $drh = DBI-
On Mon, Jun 23, 2003 at 03:24:17PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 23 Jun 2003, Tim Bunce wrote:
>
> > We can't do much with reports of core dumps without a stack trace
> > from the core file, or at least a DBI trace().
>
> Sorry about that, here's a GDB trace:
>
> Program received sig
>
> I recently upgrading a Win32/Activestate system to
> ActiveState build 806 with DBD::ODBC 1.05 and DBI 1.37. I
> find that I now get errors of the following type when I try
> to create a view over DBD::Proxy from my Linux box.
>
> DBD::Proxy::db do failed: Server returned error: Failed to
On Mon, 23 Jun 2003, Tim Bunce wrote:
> We can't do much with reports of core dumps without a stack trace
> from the core file, or at least a DBI trace().
Sorry about that, here's a GDB trace:
---
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run ./t
We can't do much with reports of core dumps without a stack trace
from the core file, or at least a DBI trace().
Tim.
On Mon, Jun 23, 2003 at 09:45:24AM -0400, [EMAIL PROTECTED] wrote:
> Greetings,
>
> On a fully patched box running sparc Solaris 8, with perl 5.8.0 and MySQL
> 4.0.13, when I try
What book are you getting your DBI examples from?
Greg
-Original Message-
From: anthony [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2003 3:56 PM
To: [EMAIL PROTECTED]
Subject: Re: sql statment(a mind of its own)
Hi,
I tried without quotes before and same results.
Anthony
Greetings,
On a fully patched box running sparc Solaris 8, with perl 5.8.0 and MySQL
4.0.13, when I try to run the following test script, I get a core dump:
-
use DBI;#establish connection to the database
$driver = "mysql";
$drh = D
From: Brian McCauley <[EMAIL PROTECTED]>
> It would appear that NUM_OF_FIELDS fetched after the execute() for a
> CREATE VIEW statement crashes out. I am able to reproduce this with a
> simple script running on the Win32 box...
>
> use strict;
> use warnings;
> use DBI;
> DBI->trace(11);
> my $db
I recently upgrading a Win32/Activestate system to ActiveState
build 806 with DBD::ODBC 1.05 and DBI 1.37. I find that I now get
errors of the following type when I try to create a view over
DBD::Proxy from my Linux box.
DBD::Proxy::db do failed: Server returned error: Failed to execute method Ca
Mark,
Thanks -- this has been reported on dbi-users and fixed for the next
release.
Jeff
>
>
> Hi
>
> DBD::ODBC 1.06 June 19, 2003 has a minor Makefile.PL bug:
>
> config :: $(changes_pm)
> @$(NOOP)
>
> ...has spaces instead of tab before the command. This causes
> make
Hi
DBD::ODBC 1.06 June 19, 2003 has a minor Makefile.PL bug:
config :: $(changes_pm)
@$(NOOP)
...has spaces instead of tab before the command. This causes make(1) to
complain
make: Fatal error in reader: Makefile, line 312: Unexpected end of line
seen
--
Regards, Ma
Tim,
When I try to run the 'make' command I get the error :
oci8.c: In function `init_lob_refetch':
oci8.c:1642: `OCI_ATTR_OBJ_NAME' undeclared (first use in this function)
oci8.c:1642: (Each undeclared identifier is reported only once
oci8.c:1642: for each function it appears in.)
I believe it
Wait for the next release or hack out the code that uses OCI_ATTR_OBJ_NAME.
Tim.
On Mon, Jun 23, 2003 at 02:36:21PM +1000, Matthews, Sue [IBM GSA] wrote:
> Tim,
>
> When I try to run the 'make' command I get the error :
> oci8.c: In function `init_lob_refetch':
> oci8.c:1642: `OCI_ATTR_OBJ_NAME'
On Sun, Jun 22, 2003 at 04:10:23PM -0700, Michael A Chase wrote:
> On Sun, 22 Jun 2003 03:29:39 +0100 Robbie Armour <[EMAIL PROTECTED]> wrote:
>
> > I use MySQL text fields as general repositories for code, data etc
> > but find that numbers are rounded to two decimal places. This does
> > not ha
I wonder if anyone has seen this issue ...
We have a successfully compiled DBD 1.12 and 1.14 running on a RedHat
7.2 server -- when setting RowCacheSize to a number more that 1000 we
garbled data -- Also using the -1000 value does the same. I have seen a
few tidbits of data on the net and Oracle's
16 matches
Mail list logo
