Well not really much DBI can do for you. You usually start from scratch trying
to write SQL that is not Driver Specific though that can be hard.
you are usually stuck with something like this
sub edit_sql {
my ($self, $sql) = @_;
if ($self->isPostgres) {
return InformixToPgs
I would agree MySQL my not be the platform you want. It is limited in what it
can do. I would give Postgress SQL a go. You have the use the 'pg_lo_???'
functions to manipulate your objects. They work quite well.
By the way saving images, mp3 etc as blobs or lobs to a DB is not used in
m
Hmm unless you change the installed clients you DBD::Oracle should still work.
as 11->12 should work
If you are having problems you most likely will have to recompile DBD::Oracle
against the new client
Checking DBD::Oracle I see it hasn't seen an update for at least 4 years or so
and therefor
:25 AM
To: John Scoles; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle
John,
Thanks so much for your reply!
I have put off this work for a few years and now the pressure is on - the
original box and OS are so old that the DBA and System Engineer and the
Oper
Hmm this type of DBD::Oracle debugging will be tricky.
Could be almost anything. You are jumping versions in a big way but that still
should be ok
A few questions
1) What is the ORA-NN in question
2) Set trace to 15 to see if that give you more details
3) What are the type of fields?
Well isn't he is calling with the alias 'fetch' and he is calling it in I think
scalar context
my ($row) = $s->fetchrow_array;
vs
if ($price_sth->fetch)
There is the odd chance that he is doing the SQL against a 'view', 'cursor'
or alike but I doupt that is it.
> Date: W
You are fetching off the end of a cursor so you would expect an error on any sql
Would be the same sort of thing as
my @test= (1,2);
print $test[100];
If you know your recordset will be small I would use fetchall_arrrayref or
fetchall_hashref rather than just fetch.
The normal way
i, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> > Well I did do some testing. The leak was very small (1k over 10 min run)
> > but only when one does
> > $shift->FETCH( 'ParamValues' ),
> > in the child callback.
>
With of course the older DBI <
ORA_VARCHAR2_TABLE)
>
> On Fri, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> > Well I did do some testing. The leak was very small (1k over 10 min run)
> > but only when one does
> > $shift->FETCH( 'ParamValues' ),
> > in the child callback.
>
obox.com; byter...@hotmail.com
> CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
>
> On 31/01/14 16:21, Tim Bunce wrote:
> > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
A final note on this.
Seems there was a very very long unknown bug in DBI which was only fix a few
days ago wiht DB 1.6.31
http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
The end result of this bug was that when callbacks are used on the statement
handl
nk testing the latest DBI/DBD::Oracle is the best thing
to do first.
á á Martin
á á á á On Fri, Jan 24, 2014 at 12:09 PM, John Scoles mailto:byter...@hotmail.com> <mailto:byter...@hotmail.com
<mailto:byter...@hotmail.com>>> wrote:
á á á á á á áAs Martin said that is rather
8916008
> > 1 <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/
> >
> > Might have been interesting if we knew what was in it.
> >
> > Perhaps you could get ParamValues just before execute and if execute fails
> > catch it and Dumper them.
> >
>
ils
catch it and Dumper them.
use Data::Dumper;
.
.
my $pv = $sth->{ParamValues};
eval {
$sth->execute;
};
if (my $ev = $@) {
print Dumper($pv);
die $ev;
}
However, I still think testing the latest DBI/DBD::Oracle is the best thing to
do first.
Martin
On Fri,
do first.
Martin
On Fri, Jan 24, 2014 at 12:09 PM, John Scoles mailto:byter...@hotmail.com>> wrote:
As Martin said that is rather old version of DBD only 3 since native
exe_array was introduced 1.18, and I rember there being some leaks in early
version of the native exe_array.
As Martin said that is rather old version of DBD only 3 since native exe_array
was introduced 1.18, and I rember there being some leaks in early version of
the native exe_array.
If you can upgrade you DBD.
Yyou might try to set the 'ora_maxarray_numentries' on you binds as well as
that
No time to look at it today but these two sites might help
http://coding.derkeiler.com/Archive/Perl/perl.dbi.users/2006-12/msg00029.html
or
http://www.pythian.com/blog/fixing-the-dreaded-unable-to-locate-an-oracle-mk-proc-mk-or-other-suitable-mk-error-in-dbdoracle-insalls/
> From: j
Hmm??
DBI just does not 'stop' working from one day to another.
What I suspect has happened is one of the following
1) Some-one have change the DSN on your DB
2) Some-one has changed permissions on the DB file
3) As you are not getting an error you might be connected but your DB file is
g
> Date: Wed, 26 Jun 2013 08:26:36 -0400
> From: a...@dancingjars.com
> To: dbi-users@perl.org
> Subject: cross database queries?
>
> I want to write a query like:
>
> select clients.client.client_id, columnar.sales.total_sales,
> web.page_hits from clients, columnar, web
> where clients.clien
It should just work as long as you did not change your Oracle client.
Most of the time Oracle clients are compatible two forward and two back.
> Date: Mon, 10 Jun 2013 17:54:59 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: douglas.e.prin...@citi.com
> Subject: (Fwd) Quick P
That will be a bit of a problem and a bugger to fix.
I can only offer a general solution as each case is different but the short
answer is yes you can run 32bit perl and 64 bit oracle together.
1) you have to get the 32bit oracle instant client for the version of oracle
you want to use
2) t
> From: john...@pharmacy.arizona.edu
> Subject: Trouble installing DBD::Oracle in OS X 10.8 ; Oracle 32 bit drivers
> the issue?
> Date: Mon, 17 Dec 2012 10:15:04 -0700
> To: dbi-users@perl.org
>
> So I think I've found the bad news part of my recent update 10 OS X 10.8…
>
> DBI installed jus
Well I would do something like
select 1 from dual
rather thatn '*'
It sounds like your DB coonection string is not correct.
Cheers
> From: amaresh.poth...@gmail.com
> Date: Mon, 19 Nov 2012 16:59:09 +0530
> Subject: Perl DBI Hangs while execute()
> To: dbi-users@perl.org
>
> Hi All
> Date: Mon, 12 Nov 2012 19:04:56 +
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> CC: kevin.k...@gmail.com
> Subject: Fwd: DBD::Oracle Schema different than User question
>
> Hi Kevin,
>
> I've forwarded your email on to the dbi-users li
.
Cheers
John Scoles
> Date: Tue, 28 Aug 2012 13:06:59 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: rune.hens...@trapezegroup.eu
> Subject: (Fwd) DBD::Oracle Continuous Query Notification
>
> - Forwarded message from Rune Henssel -
>
> Date
Last time is did it Dan, was a year or two ago and I has the same sort of
problem, no xlc, so I just used the recipe here
http://search.cpan.org/~pythian/DBD-Oracle-1.47_00/lib/DBD/Oracle/Troubleshooting/Aix.pod#Using_gcc_C_Compiler
should work for you. Though you might have to install the 'C
have a look at
http://search.cpan.org/~pythian/DBD-Oracle-1.46/lib/DBD/Oracle/Troubleshooting.pm
it should answer most of your questions
> From: james.war...@acxiom.com
> To: beginn...@perl.org; dbi-users@perl.org
> CC: newbie01.p...@gmail.com; rob.di..
Funny, you are right it does not look incorrect
give this a quick try
$csr_insert->bind_param_inout(':new_id', \my $new_resource_id, 99);
Was this working before?
Did it break after an upgrade or something??
cheers
John
>
> Fr
Short answer no. I would not see any reason why you would need to install the
instance client as well.
In the long run it depends on what you are doing. If you are going to use perl
for only loacal access then no need for the instanct cleint. If you want to
use Perl for say connecting via
Are you selecting Lobs or Blobs??
Could be an issue. Crank up the ora_verbse to 15 to get everything.
It would do an extra select to get any lob types.
I will have to have a look at the full thread sometime tomorrow.
Cheers
John
> Subject: Re: It's a bad day here...
> From: john...@pharm
> Date: Fri, 30 Mar 2012 09:10:41 +0100
> From: martin.ev...@easysoft.com
> To: john...@pharmacy.arizona.edu
> CC: dbi-users@perl.org
> Subject: Re: Error I've not seen before from oracle DBD
>
> On 30/03/12 09:02, Martin J. Evans wrote:
> > On 29/03/12 22:10, Bruce Johnson wrote:
> >>
> >> On
Ran into that one, or nearly like it, a while back. Was not able to find a
OCI/DBD solution so I just modified my code like this
$sth->execute_array({},\ @undefs, \@undefs, \@data_ids, \@set_ids, $ct_none);
so I had an array for each param
a quick kludge only.
If I get a little time this
I wish I could give you a 100% tumbs up on this but...
It should work without problems as I have used Oracle Wallet many times before
and in theory the OCI client and not the perl code should take care of all that
for you.
So if you can connect with DBD::Oracle it should just work.
You mig
I would have to agree with Martin. The bigest jump, code-wise was the jump
between 16~17 so you are very much out of luck if you want to get anything
fixed in 16 or eariler. I you update to 17 first and see what happens you will
get a good idea if you can update any futher. I also depends on
bind_param_inout_array, (0 in the example), "maxlen"
> is required by DBI but not used by DBD::Oracle"
>
> Is this true for the bind_param_inout method? as well?
bind_param_inout is implimented fully on the DBI side so what ever the DBI spec
says it needs it then it n
Let me chime in here as well. Though I rarely ever use UTF but I beleive you
can set and or override any of the ENV values
this at the handle level which I think is the best solution to the orginal
problem
>From the POD
ora_charset, ora_ncharset
For oracle versions >= 9.2 you can specify th
t
> > the native DBD::Oracle/OCI object selections so we might be looking at
> > something else in DBD::Oracle. Will have to load this puppy up and have a
> > look at the verbose trace
> >
> > Will have to wait till monday though swamped with SlJs here today
&
t;
> Will have to wait till monday though swamped with SlJs here today
>
> Cheers
> John Scoles
>
> > Date: Fri, 9 Dec 2011 14:01:43 +
> > From: martin.ev...@easysoft.com
> > To: dbi-...@perl.org
> > CC: dbi-users@perl.org
> > Subject: Problem wit
something else in
DBD::Oracle. Will have to load this puppy up and have a look at the verbose
trace
Will have to wait till monday though swamped with SlJs here today
Cheers
John Scoles
> Date: Fri, 9 Dec 2011 14:01:43 +
> From: martin.ev...@easysoft.com
> To: dbi-...@perl.org
I would agree with that.
One thing alsot to check is to make sure the Perl that you are using is the
same as the one DBD::Oracle was compiled on. Many times a use's perl could be
a completed seperate path that the root perl
cheers
John
> Date: Fri, 9 Dec 2011 13:48:41 -0600
> From: mn...
> From: b...@wards.net
> Date: Sun, 4 Dec 2011 19:15:20 -0800
> Subject: Re: Maintaining simultaneous support for two Oracle versions in DBI
> To: smi...@latfor.state.ny.us
> CC: dbi-users@perl.org
>
> Aren't the Oracle driver libraries backward compatible? If you link DBD to
> the Oracle 11
I went through this about a year or so ago with another client his was 8 and 11
so a real big differace.
It can be done but you have to reaname or at least alias some of the oracle
files as well or else they will step on each other. That is if you are usng
linux. It is a little easer with wi
inst Oracle full installs.
>
> On 07/11/11 17:56, John Scoles wrote:
> >
>
> >> What am I doing wrong?
> >
> > Most likely nothing:)
>
> It turns out that I was doing something quite seriously wrong:(
>
> The make file Oracle recommend for build
pathched a little to fix the problem.
Hard to debug without access to the box or at least a box that looks like the
one you are trying to install on.
Are you using 64 bit perl?
cheers
John Scoles
> Date: Mon, 7 Nov 2011 17:15:47 +
> From: c...@cam.ac.uk
> To: dbi-users@perl.
next.
>
> As for how much anyone else might find use for thisprobably not
> a wide audience. But it is a nice hack!
>
> Thanks for the pointers.
>
> Quoting John Scoles (byter...@hotmail.com):
> >
> >
> > > Date: Thu, 27 Oct 2011 14:14:03 -0400
g with the C++ object
>
> $cpp_dbh->make_legacy_call_to_db();
>
>
>
Yup that should work I didn't put two and two together and figure you already
had XS for the C++.
It could be something we could add to DBD::Oracle but I would return all of
the handles not just the few
> Date: Thu, 27 Oct 2011 18:42:23 +0100
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
>
> On 27/10/2011 17:43, John Scoles wrote:
> > Hmm!!
> >
> > Well y
The C++ code could then be integrated seemlessly with my
> Perl code. As time allows, I would gradually peel away functionality
> from the legacy C++ libraries and implement it in Perl. But to
> ease the migration path, this approach seemed to have some merits.
>
>
> Quoting
> Date: Wed, 26 Oct 2011 21:46:30 -0400
> From: bro...@deseret.com
> To: dbi-users@perl.org
> Subject: DBD-Oracle - obtaining OCI handles from $dbh
>
> I have created some Perl bindings for some existing custom C++
> libraries.
>
> One of these C++ libraries implements a class that uses Ora
bound to be a few that
slip though the cracks.
Cheers
John Scoles
> Date: Sat, 15 Oct 2011 15:24:59 -0400
> Subject: Re: DBD::Oracle 1.25 and DRCP
> From: frie...@gmail.com
> To: byter...@hotmail.com
> CC: dbi-users@perl.org
>
> Thanks John!
>
> that seems to have
ould (if it can) show you some place in the trace
Useing DRCP Connection
just after it reports on your NLS env
Just need to connect no need for any qurreries etc
cheers
John Scoles
> Date: Fri, 14 Oct 2011 18:53:09 -0400
> Subject: Re: DBD::Oracle 1.25 and DRCP
> From: frie...@g
Hard to say.
Not sureif the way you are pasing in the sid will work.
add dbd_verbose=>15
to the conection options hash
Run the perl and post the output on this thread
so I can have a look at what is going on.
Just do a simple connect no need for any other DBI stuff.
I would also give t
Why even use DBD::ODBC?
Why not use DBD::Oracle?
Cheers
John
> Subject: Re: DBD::ODBC fails, SQL*Plus works
> From: john...@pharmacy.arizona.edu
> Date: Wed, 5 Oct 2011 10:53:48 -0700
> CC: dbi-users@perl.org
>
>
> On Oct 5, 2011, at 9:09 AM, Scott Stansbury wrote:
>
> >
> > It return
I would hope it would depend on which type of DB you are trying to proxy to.
If the DB at the other end of the proxy does not support 'begin_work' and
'commit' or 'transactions' then DBI Proxy will not magically enable it.
What flavour of DB is behind the proxy??
I have never used it for
helps
Cheers
John Scoles
> Subject: Connecting to Oracle 11g with perl 5.6.1
> Date: Tue, 4 Oct 2011 21:04:16 +0530
> From: s...@cisco.com
> To: dbi-users@perl.org
>
> Hi,
>
>
>
> I have a perl program that is using Perl 5.6.1 and Oracle 10g. We have
> migr
> Date: Thu, 15 Sep 2011 09:26:41 -0700
> From: tigerpeng2...@yahoo.com
> Subject: Re: Tail Module + DBI Module, can\'t keep up!
> To: bphe...@gls.com
> CC: dbi-users@perl.org
>
> Separate the process into two steps and figure out which step should be fixed
> first.
>
> 1. Parse the log wit
You will most likely have to reinstall DBD::Oracle and the Oracle client one
your new target linux box
try
Perl -MDBD::Oracle -e 'print DBD::Oracle::VERSION'
To see if it is installed on your new box.
If not you will have to get it from CPAN as well as an Oracle Client
I would use the
I think you can turn that one off by using WARN
http://search.cpan.org/~timb/DBI-1.616/DBI.pm#Warn
if memory serves me correctly it is a true 'warn()' and not a PrintWarn.
It is very deep in the code. I think in Driver.xst.
It is at the DBI side of things and has nothing to to with DBD::
Doesn't seem to be a DBD for Netezza but you can connect though 'ODBC' so you
will be able to use DBI.
Perhaps in the long run you might want to write a DBD yourself as long as there
is some sort of interface from IBM.
Doesn't seem to be much of anything on Netezza on CPAN yet.
Cheers
Check the NLS_LANG and other local ENV setting such as Country etc. setting on
the box where your client resides.
You might have to change it to one that can display.
Make sure the data is going in correctly first and that your display can
display it.
Hope this helps.
Cheers
John
>
We will need a little more to go on than that. At a min we need
1) DBI version
2) DBD driver name and version
3) Database system name and version
4) OS
What would be perfect is a perl script that recreates the error.
Cheers
DBI users
> Subject: Segmentation fault
> Date: Mon, 6 Jun 2011
currency string
> nls_iso_currency string
> nls_language string AMERICAN
> nls_length_semantics string CHAR
> nls_nchar_conv_excp string FALSE
> nls_numeric_characters string
>
> NAME TYPE VALUE
> ---
> --
&
That only ocures when the nclob going in is not compatiable with the nclob
field you are trying to stuff it into.
one thing that wil give us a little more info is to connect with dbd_verbose=9
on the attributes and that will tell us you NSL setting.
also get your DBA to check
NLS_CHARACTE
Well looking at the code there does not seem to be any get_info in DBD::Sybase
so I think you are out of luck
Cheers
John
> From: eric.b...@barclayscapital.com
> To: dbi-users@perl.org
> Date: Fri, 3 Jun 2011 11:38:59 -0400
> Subject: DBD::Sybase and DBI->get_info()
>
> As we migrate our co
Simple connection problem.
Try to connect SQLPlus if you can do that then you can use DBD::Oracel
Try the same connection string in DBD:Oracle
Hope this helps
cheers
John
> CC: dbi-users@perl.org
> From: jona...@gmail.com
> Subject: Re: Need Help with DBI for oracle
> Date: Fri, 3 Jun 201
May 2011 17:05:19 -0400
> Subject: RE: AIX 5.3 DBD::Oracle issues
>
> Sorry I did forget to include that I am working with 1.27. I checked the
> oci.def and OCIPing is in it. I am very perplexed as this same install worked
> fine on another node.
>
> From: John Scoles [mailt
Hmm talk about ancient history.
Not a but in either me thinks
I believe this is the default behaviour of early OCI clients like OCI 7 to
trim all varchars. This changed for some reason by Oracle in
OCI 8 and then changed again by Oracle in 9 and later clients. There are
different ways th
Date: Wed, 18 May 2011 13:03:34 +0100
John,
Irrespective of I calling in Java or executing it on the SQL developer or in
TOAD, I am getting the same response time when compared to executing the SQL’s
separately
Regards
P S Jameel Ahamed
From: John Scoles [mailto:byter
Does this have anything to do at all with DBD::Oracle???
You mentioned you are calling this with JAVA??
Where is the Perl code??
> From: jaha...@idexcel.com
> To: martin.ev...@easysoft.com; dbi-users@perl.org; byter...@hotmail.com;
> carlso...@llnl.gov; tim.bu...@pobox.com
> Subject: RE: (Fwd
What is the issue exatly?
It is just slow??
Can you give us some examples code to play with.
Slowness can be caused by anything from low-ban width, poor SQL, a badly
partiioned DB or just too much data??
We need to know the version of DBD::Oracle you are using as well
Cheers
John
>
Martin Evans would be the expert on that. But it does sound funny that
TEXTSIZE is working and LongReadLen is not?? LongReadLen should work no matter
the driver.
Perhaps you should try DBD::ADO
> From: eric.b...@barclayscapital.com
> To: dbi-users@perl.org
> Date: Tue, 17 May 2011 12:11:55
Are you uisng activestate Perl?
You will also have to insall DBD::Oracle and an instantclient as well.
If not you will have to compile DBD::Oracle yourself (takes a little while but
it can be done) see the windows readmes to find instrunctions
Cheers
John Scoles
> Date: Fri, 29
On 18/04/2011 3:29 PM, Tim Bunce wrote:
[redirected to dbi-users list]
On Fri, Apr 15, 2011 at 03:05:59PM -0400, John Scoles wrote:
I was given a patch for DBD::Oracle today the just of it was to open
up the OCI commands for starting up and shuting down the DB.
So the question is would this
On 13/04/2011 5:19 PM, mmilli...@fruit.com wrote:
Well nothing special
The latest DBI and DBD::Oracle and I would go with the latest version of
the Oracle instant client 11g.
Compiling for AIX is always a bit problematic depending on how the
system is set up, how the Perl was compiled and wh
I will have to look into this one in detail later next week as I am off at a
conferace this week. Seems like something got in there.
can you send me run with DBD_Verbose=7
Cheers
John
> Date: Thu, 24 Mar 2011 16:26:00 +0100
> From: alexan...@foken.de
> To: dbi-users@perl.org
> Subject: DBD:
Release
Cadidates, hint hint nudge nudge ;) ;)
Cheers
John Scoles
> Date: Thu, 24 Mar 2011 13:27:20 +0100
> From: alexan...@foken.de
> To: dbi-users@perl.org
> CC: jason.thurs...@gmail.com
> Subject: Re: Fwd: Error 'making DBD:Oracle 1.28 on Cygwin W
>
> DBD::Oracle
On 21/03/2011 2:49 PM, Tim Bunce wrote:
- Forwarded message from Satish Patil -
Date: Mon, 21 Mar 2011 07:37:45 -0700 (PDT)
From: Satish Patil
To: tim.bu...@pobox.com, s.goeld...@eurodata.de
Subject: Re: DBD::Oracle: table_info, PUBLIC schema
X-Mailer: YahooMailClassic/11.4.20 YahooMai
arset on your
connection string with DBIx
cheers
John
On Thu, Mar 10, 2011 at 4:01 PM, Ivan Wills wrote:
> On 10 March 2011 10:09, John Scoles wrote:
>
>> CSID in this case is the the national character set in the first
>> environemtn it is 873 in the second it is 1 so it
CSID in this case is the the national character set in the first environemtn it
is 873 in the second it is 1 so it cannot traslate betwwen one and another.
As well it is the csform =0 that worries me more as that should come out as the
as one of the allowable something like SQLCS_NCHAR or SQL
Common to all DBD me thinks. Me thinks you only get in or out scalars (ie
strings) unless you tell your DBD differently
I think you have to use $sth->bind_co
to get your int back as an int try something like this
$sth->bind_col(1, undef, { TYPE => SQL_INTEGER });
hope this helps
> From
s into the picture?
-Mark
-Original Message-----
From: John Scoles [mailto:sco...@pythian.com]
Sent: Thursday, February 17, 2011 4:10 PM
To: dbi-users@perl.org
Subject: Re: Problem with UTF8 and array binding
On 17/02/2011 3:05 PM, Bobak, Mark wrote:
Perhaps you have to declare you in
On 17/02/2011 3:05 PM, Bobak, Mark wrote:
Perhaps you have to declare you in type as a NCLOB??
Cheers
John
Hi all,
I'm running into a 'PLS-00418: array bind type must match PL/SQL table row
type' error, but only when passing UTF8 data.
The details are as follows. I have a PL/SQL packaged f
On 16/02/2011 2:45 AM, Ivan Shmakov wrote:
Well if you are using DBD::Oracle I would just use an Oracle Wallet to
do that for you.
I am sure there are other solutions as well.
Cheers
BTW, what is the best current practice to pass ->connect ()
$password to a command-line Perl
te you can localize the $SIG{} so this should solve the
problems with $SIG{} events that sometimes occur when using DBD::Oracle
Finally I would like to thank Martin Evans for volunteering to be
another co-maintainer of DBD::Oracle
Cheers
John Scoles
Changes
Added connection attribute 'o
On 11/02/2011 1:16 AM, Jayadevan M wrote:
Hmm looking at the env and the MakeFile.pl output perhaps your
ORACLE_HOME is not correct
I would give /u01/app/oracle/product/10.2.0/ a try rather than
/u01/app/oracle/product/10.2.0/db_1
just a suggestion
Cheers
John
Hi,
I am tying to install DB
d even if it is it has to be the exact same version of xlC
Hope this helps/
If all else fails rebuild your perl from scratch with xlC t if you have a
few hours to wast;)
Cheers
John
>
> -Original Message-
> From: John Scoles [mailto:sco...@pythian.com]
> Sent: Friday, Janua
Installing dbd oracle on any version AIX has always been problematic.
Usually you have to rebuild your perl with the exact same version of
compiler that compiled the perl.
If you are using the Perl that comes with AIX that may be hard to do.
As well there are always 64-32 bit issues.
Can you po
Yeah that has been around for a long time
I will put that into trunk so it will get into 1.28 which should be out next
week sometime.
Thanks allot Charles
Cheers
John
On Fri, Jan 28, 2011 at 10:25 AM, Charles Jardine wrote:
> Attached is a patch against DBD::Oracle version 1.27 which corrects
I would say simply convert over to Apache::DBI you would not have to change
any of your code except
use DBI; to
use Apache::DBI
Will most likely solve any problems you are having
cheers
On Thu, Jan 27, 2011 at 4:26 PM, Bill Ward wrote:
>
>
> On Thu, Jan 27, 2011 at 4:04 AM, Jo
On 26/01/2011 3:35 PM, Bill Ward wrote:
On Wed, Jan 26, 2011 at 12:27 PM, John Scoles wrote:
Or, is there some way to verify the OCI environment and reset it when
it is found to be unusable - in other words, trap the
"OCIHandleAlloc(OCI_HTYPE_ERROR)" error and reconnect?
Well n
On 25/01/2011 8:21 PM, William Ward gmail wrote:
In regards to this thread:
http://www.mail-archive.com/dbi-users@perl.org/msg32115.html
(found via google)
I'm having the same problem at $JOB and before we throw ora_envhp=>0
into our connect attribute, we were wondering if this will cause
perfor
On 25/01/2011 10:40 AM, Jonathan Leffler wrote:
On Tue, Jan 25, 2011 at 07:28, John Scoles <mailto:sco...@pythian.com>> wrote:
On 25/01/2011 10:25 AM, Jonathan Leffler wrote:
Please change the subject line to match the content of the
question!
(Old subj
On 25/01/2011 10:25 AM, Jonathan Leffler wrote:
Please change the subject line to match the content of the question!
(Old subject: "DBI 1.611 + DBD::mysql 4.016 = segfaults on Ubuntu 10.10
amd64 ?"
On Tue, Jan 25, 2011 at 06:54, Tony Espositowrote:
Hello Tim,
Just curious, Tim, when is DBI
On 05/01/2011 4:31 AM, ZHANG Jiaqiang A wrote:
Yep those are two known bugs with 64bit system.
Still working on getting rid of them. It is hard to reproduce but one
of the ones we will be fixing soon
The good news is unless you are using embedded objects like VARRY,
OBJECT or TABLE you ca
e is DBD::Oracle will want to create a new session for your
ORA_CLOB to use to insert all of your clob no matter how big.
I works without the ORA_CLOB because it is just a straight insert up to
a set value ,the value of 'LongReadLen' me thinks?
Hope this helps.
Cheers
John Scole
that a blocker for DBD?
No it is a separate and deprecated hunk of code for perl 4. It may be a
symptom of a deeper problem so we need to see the Makefile.pl and make
output to know for sure.
Cheers
John Scoles
Thanks in advance,
Carl Furst
CMS Developer
MLB
Thanks for that
However I an not sure what you did
dbd_phs_ora_varchar2_table_
>
> fixup_after_execute
>
> with
>
>dbd_phs_ora_varchar2_table_fea
> in
>
does not make any sense to me. I thinks your email was cut off somehow
can you attach a copy of your DBDIMP.C file so I can have a l
I went through this and checked the patch and it was not fully applied
I have patched trunk and your can find it here
http://svn.perl.org/modules/dbd-oracle/trunk
Please note It will be release in 1.28 not 1.27
Cheers
John Scoles
On Tue, Sep 14, 2010 at 6:48 PM, John R Pierce wrote:
>
for 1.28
Cheers
John Scoles
On Wed, Aug 4, 2010 at 2:27 PM, LK wrote:
> In the process of moving from centos 4 to a centos 5 machine one
> script stopped working. I distilled it down to this problem :
>
>
> #! /usr/bin/perl -w
> use strict;
> use DBI;
>
dbd_st_execute slow speed
On 2010-12-16 07:15:02 -0500, John Scoles wrote:
On 16/12/2010 7:06 AM, Ludwig, Michael wrote:
-Original Message-----
From: John Scoles
More likely SQLplus is spawning a thread while DBD::Oracle does not.
You mean performing the actual work in the backgro
1 - 100 of 553 matches
Mail list logo