Are you saying the wrong value is getting posted to the procedure?
Jeff
> -Original Message-
> From: Roger Perttu [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 07, 2002 8:47 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Bug in DBD-ODBC 0.45_18
>
>
> This is for the
Sorry this has taken so long to respond to.
> -Original Message-
> From: Roger Perttu [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 03, 2002 12:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bug in DBD-ODBC 0.45_16
>
>
> Jeff,
>
> I've been busy but finally managed to test the new ve
On Monday, October 14, 2002, at 01:10 PM, Michael Peppler wrote:
> On Fri, 2002-10-11 at 14:27, Henri Asseily wrote:
>>
>> Regarding what I've dubbed DBIx::HA, here's the idea:
>>
>> There hasn't been up to now (or at least I haven't found any) a widely
>> available Perl/DBI-based system for sys
I'm very interested in the new DBD::AnyData as I use it to work with CSV
files in conjunction with DBI::PurePerl. Does the new version that's
in the works have any speed/resource/architecture improvements? I
thought it was mentioned previously that it would be revised based on
lessons learned wh
I'm downloading several million records from an Oracle database to a MySql
database and would like to use fetchall_arrayref() to do it. However, there
are so many records that my computer memory fills up and then crashes.
Is there a way of "chunking" the data coming down or do I need to use the
Has anyone else been using Perl/DBI with Apache 2.0.XX for cgi
applications? If you have, have you had problems with
print STDERR "blah"
going to the apache error log? I'm sure a related problem is
the inability of "cluck" messages to hit the error log.
Has anyone else experienced similar p
On Mon, Oct 14, 2002 at 10:42:10AM -0700, Kevin Scaldeferri wrote:
> Tim Vorce wrote:
> >It is my impression that the utf flag isn't set unless you explicitly set
> >it. That seems to impact program stuff rather than data, and that may
> >best be set by the statement
> >use utf8;
> >
>
> In Pe
I've been beating my head on this all afternoon. I've searched the web,
read the README files, and have run out of ideas.
I'm trying to build DBD-Oracle 1.12 on Solaris 7. I've got the Solaris
8.1.7 client installed in /opt/oracle/oracle8i/8170-SUN.
I've set ORACLE_HOME, ORACLE_SID, and ORACLE
Is this in the FAQ? If not, David, can you please add it:-)
Thanks a bunch.
Ilya
-Original Message-
From: Crown David T. (DNREC)
To: Kwabbi, Seth; [EMAIL PROTECTED]
Sent: 10/14/02 1:15 PM
Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
This is because your
On Fri, 2002-10-11 at 14:27, Henri Asseily wrote:
>
> Regarding what I've dubbed DBIx::HA, here's the idea:
>
> There hasn't been up to now (or at least I haven't found any) a widely
> available Perl/DBI-based system for system architects who handle
> high-availability groups of servers, eithe
On Mon, 14 Oct 2002, Kwabbi, Seth wrote:
> No, the first libclitsh.so.9.o point to the lib32 libraries, otherwise
> the make would not have worked. The issue here is more of a run time
> problem, when the Dynamic Loader attempts to load the shared library.
Then all I can think of is that the LD_
It works.
Thanks.
-Original Message-
From: Crown David T. (DNREC) [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 14, 2002 3:27 PM
To: Kwabbi, Seth
Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12
module
That do the trick? b/c I'm in the process of getting it hammere
No, the first libclitsh.so.9.o point to the lib32 libraries, otherwise the
make would not have worked. The issue here is more of a run time problem,
when the Dynamic Loader attempts to load the shared library.
Thanks.
-Original Message-
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
Se
DBD::Oracle's shared object library is linking to the only library it
finds. If it is getting "/u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0"
it is because that is the first libclntsh.so.9.0 in the LD_LIBRARY_PATH,
and if it isn't 32-bit then the problem is that LD_LIBRARY_PATH should not
in
It is 64 bit, but why is the DynaLoader using 64 bit libraries whilst
LD_LIBRARY_PATH points to the 32 bit libraries ?
Thanks.
-Original Message-
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 14, 2002 3:10 PM
To: Kwabbi, Seth
Cc: '[EMAIL PROTECTED]'
Subject: RE: W
This is because your attempting to build in a 32 bit Perl against a
64bit oracle install. Here's the solution form Stephen Clouse:
"The best solution is to edit the Makefile generated by Makefile.PL and
change all references to ORACLE_HOME/lib to ORACLE_HOME/lib32. This
will get it to use the 32
Run this command:
file /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0
If it tells you that it is a 64-bit ELF library, it's the 64-bit version.
On Mon, 14 Oct 2002, Kwabbi, Seth wrote:
> When I execute my perl code to connect to the Oracle databse using the 32
> Bit version of
> DBD-Ora
When I execute my perl code to connect to the Oracle databse using the 32
Bit version of
DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points
to the 32 bit libraries. Is there anything else that I need to set for this
to work properly ?
Can't connect to database: install_dr
On Monday, October 14, 2002, at 11:57 AM, Christopher G Tantalo wrote:
> not to be a smart ass(gonna be one anyways), but after all that work,
> wouldnt
> you want to keep your new column? :)
D'oh!
I mean drop the old column.
David
--
David Wheeler AIM:
David Wheeler wrote:
> Sorry, bad memory. It's DROP COLUMN that's been added. This is from the
> HISTORY file:
>
> PostgreSQL now supports ALTER TABLE ... DROP COLUMN
> functionality.
>
> But what that means is that you can rename your old column, add a new
> column with the new data
On Monday, October 14, 2002, at 11:50 AM, Hardy Merrill wrote:
> Are you sure - I just checked the Postgres 7.3b2 docs at
>
> http://developer.postgresql.org/docs/postgres/sql-commands.html
>
> and there is no mention of an ALTER COLUMN command.
Sorry, bad memory. It's DROP COLUMN that's been
David Wheeler [[EMAIL PROTECTED]] wrote:
> On Monday, October 14, 2002, at 11:30 AM, Hardy Merrill wrote:
>
> >Is there an easier way? What am I missing?
>
> Yes, there is: PostgreSQL 7.3. It's still in beta, but should be in
> final release soon. It finally adds good ALTER COLUMN support.
A
On Monday, October 14, 2002, at 11:30 AM, Hardy Merrill wrote:
> Is there an easier way? What am I missing?
Yes, there is: PostgreSQL 7.3. It's still in beta, but should be in
final release soon. It finally adds good ALTER COLUMN support.
HTH,
David
--
David Wheeler
Hmmm...
Might have something to do with compiling DBD::Oracle as 32 bit, gcc 3.2
has an -m64 option. I don't know if DBD::Oracle will work with 32 bit
perl if compiled that way though.
Also, CC on solaris is capable of compiling 64 bit.
> -Original Message-
> From: Kwabbi, Seth [mailto
You can't link against the 64-bit version unless your Perl (and by
extension all modules including DBI and DBD::Oracle) is built with maximal
64-bit support.
The problem is that it is not possible to "mix and match" linking 32-bit
and 64-bit libraries. If you do build your Perl as 64-bit, you wi
I am using Perl DBI to do this conversion, so this is somewhat
related to DBI.
I need to convert a column in a Postgres table from VARCHAR to
INTEGER - I don't know of an easy way to do that, so I'm assuming
I need to do something drastic like this in my conversion script:
* create a new table
Tim Vorce wrote:
> It is my impression that the utf flag isn't set unless you explicitly set it. That
>seems to impact program stuff rather than data, and that may best be set by the
>statement
> use utf8;
>
In Perl 5.8, 'use utf8' is 99% no-op. It is documented as only being
necessary to r
I wanted to know if it were possible of recuperer the
place of code SQL or the error occurred.
I could recuperer $$dbh->{errstr },
I seek more precision if that exists. Thank you and
good day.
___
Do You Yahoo!? -- Une adresse @yahoo.fr
When running make for the DBD-Oracle-1.12 module, I encounter this error:
ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF
class: ELFCLASS64
My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3
20010315 ( release). Also know if I set LD_LIBRA
Hi,
Probably,This is not a question for the dbi group.
1) Could anyone tell me how to convert an ascii value
of a char to the character itself.
Another request.
2) Could anyone give me an example of using an
showErrorStatement passing the values.
thank you.Naveen
__
using CSDK 2.80 (on Linux, at least), the output from "esql -V" has
changed. That breaks the version parsing in
DBD/Informix/Configuration.pm . Bug report below.
I made a few changes to make this script more failsafe. Don't know if
this is the best way, though.
Here are the diffs:
--- DBD/Inf
It is my impression that the utf flag isn't set unless you explicitly set it. That
seems to impact program stuff rather than data, and that may best be set by the
statement
use utf8;
Tim Vorce
Ford Motor Company
[EMAIL PROTECTED]
-Original Message-
From: Kevin Scaldeferri [mailto:[EM
Thomas A. Lowery wrote:
>Roger,
> My work with DBD-ADO and stored procedures is very limited. If you could
> provide me with a few (at least one) complete example that generates this
> error, fixing it would be much easier. Also, I haven't a lot of time to
> work on DBD-
You can't use DBI::PurePerl with a NON-pure-perl driver.
Tim.
On Mon, Oct 14, 2002 at 08:19:57AM +0200, Frederic Van de Velde wrote:
> Hi,
>
> I'm trying to run some perl (currently 5.00503) on AIX 4.3 to connect an
> Oracle 8 database on the same system (DBD::Oracle is 1.06)
> My problem is t
Hi,
I'm trying to run some perl (currently 5.00503) on AIX 4.3 to connect an
Oracle 8 database on the same system (DBD::Oracle is 1.06)
My problem is that I want to use the "HandleError" method of DBI but I
only find a pre-compiled version of DBI 1.14 which doens't have this
method yet.
As I c
35 matches
Mail list logo