first.
Martin
On Fri, Jan 24, 2014 at 12:09 PM, John Scoles byter...@hotmail.com
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
at 12:09 PM, John Scoles byter...@hotmail.com
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.
If you can upgrade you DBD
the latest DBI/DBD::Oracle is the best thing
to do first.
Martin
On Fri, Jan 24, 2014 at 12:09 PM, John Scoles byter...@hotmail.com
mailto:byter...@hotmail.com mailto:byter...@hotmail.com
mailto:byter...@hotmail.com wrote:
As Martin said that is rather old version of DBD only 3 since
On Fri, Jan 24, 2014 at 12:09 PM, John Scoles byter...@hotmail.com
mailto:byter...@hotmail.com mailto:byter...@hotmail.com
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
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=entryid=5570blog_id=2165
The end result of this bug was that when callbacks are used on the statement
handle
: 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
, 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.
If it doesn't keep growing with more call then it's not a leak.
Tim what would
-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 1.63,
I did not see a leak with 1.63 no matter how long I let it run
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
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:
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
com>
Sent: December 18, 2017 11: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 Sys
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
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
501 - 514 of 514 matches
Mail list logo
