ERROR OCINlsEnvironmentVariableGet(OCI_NLS_CHARSET_ID) Check NLS
You need to set some environment variables
$ENV{ORACLE_HOME} = ...;
$ENV{OCI_NLS_CHARSET_ID} = ...;
From: Rakesh Ramachandran
Sent: February 3, 2017 1:11 AM
To: Deven T. Corzine
Cc: dbi-dev@perl.or
Yep one of the more unplesnt parts of being a DBDer, Looking back I had to
drop a few #ifdefs when I was the more active with DBD::Oracle.
I just made up a chart on the POD
http://search.cpan.org/~pythian/DBD-Oracle-1.66/lib/DBD/Oracle.pm#WHICH_VERSION_OF_DBD::ORACLE_IS_FOR_ME?
I my c
I had a change to go though it and it all looks ok.
By the way 'dying' is correct the word you are thinking of is 'dyeing'
English is such a silly language;)
Cheers
John
> Date: Tue, 11 Jun 2013 08:03:54 +0200
> From: h.m.br...@xs4all.nl
> To: dbi-dev@perl.org
> Subject: Re: [PATCH] Spell
Hmm you always come up with the head scratchers,
You are most likely on the right track. Somewhere way in the back of my mind I
recall that the fetchall_arrayref was optimized for speed, and so the binding
was left out but I am going back almost 10 years by memory.
Do the other DBD do the
Should Allways work for 1 DB version forward and one back.
So a 10 instantshould should work a 9,10 and 11 at least that is the theory.
Oracle is a little unclear on what a Version is.
What I usually do is complie with the instant client and depoly it with the
compiled code. This is how
A pure perl version of the DBI already exists so I I take it you want to write
a DBD::Blueprints? There are a number of pure perl DBD however I am not sure
what Blueprints is??? Can you give us a link to it so I can at least see what
you are writing a driver for??
Cheers
John
> From: libsys
you might wan to try visit_handles
http://search.cpan.org/~timb/DBI-1.623/DBI.pm#visit_handles
and visit_child_handles
http://search.cpan.org/~timb/DBI-1.623/DBI.pm#visit_child_handles
Send a code ref down the pipe and close the ones that have been idle for a
while.
Just a though.
> Date: Mon, 28 Jan 2013 19:33:46 +
> From: martin.ev...@easysoft.com
> To: dbi-dev@perl.org
> Subject: Re: bind_param () - did something change?
>
> On 28/01/2013 19:03, John Scoles wrote:
> > I do not think so. That section of DBD::Oracle code does need some rewor
I do not think so. That section of DBD::Oracle code does need some rework as it
was written for Oracle 8. It should be updated to use the Oracle 10+
functionality for both select and updates. Alas one never seems to have any
time work, (well finish actully) the work on this one. CheersJohn >
> Date: Thu, 17 Jan 2013 19:47:06 +
> From: martin.ev...@easysoft.com
> To: byter...@hotmail.com
> CC: c...@cam.ac.uk; dbi-dev@perl.org
> Subject: Re: Problem with procedures returning a SYS_REFCURSOR which is not
> open/executed - possible fixes
>
> On 17/01/2013
> Date: Thu, 17 Jan 2013 13:48:15 +
> From: martin.ev...@easysoft.com
> To: c...@cam.ac.uk
> CC: dbi-dev@perl.org
> Subject: Re: Problem with procedures returning a SYS_REFCURSOR which is not
> open/executed - possible fixes
>
> On 17/01/13 12:26, Charles Jardine wrote:
> > On 15/01/13 23:
Hmm you sure pick the head scratchers.
My first thoughts where why whould you make such a procedure?? But then I
relaisze it could have some use when prototying/develpopeing ect.
Looking at
'DBD::Oracle attempts to describe statements which are initialized but not
executed'
We might be
Well I made that ping patch for DBIx::Connector a few months ago on one of my
production boxes with no impact but then again I am not doing anything fancy
(no rac raid etc).
If it is critical to DBDx::Connector to ensure a query can be run then no, if
you are going for 100% work alike betweeen
> From: g...@turnstep.com
> To: dbi-dev@perl.org
> Subject: Re: Oracle ping
> Date: Mon, 5 Nov 2012 02:47:06 +
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> Also by the time an application does execute some SQL, the the
>> connectio
You will have to give us the DBD::Oracle version as well.
ORA-12514 is TNS:listener does not currently know of service requested in
connect descriptor
http://ora-12514.ora-code.com/
so I sort of suspect that you lintener and or service is not set up correctly
to handle the language or the DB
Boy I think I really started something here.
I just heard back from OIC connection over at Oracle and here is his two cents
on the issue
"From an OCI point of view the OCIPing/OCIServerVersion calls are as
good as it gets for basic aliveness of the connection. I'd never have
thought they would
Hi guys had some time today to play again
Seems we have one of three choices
SvREFCNT_dec(tuples_utf8_av);
as pathced
or
av_clear(tuples_utf8_av);
at the send of the 'i' loop or
sv_2mortal((SV*)tuples_utf8_av);
at the begining
I have tried them all and they all get rid of the l
5 +0200
> Subject: Re: Patch proposal for leak in DBD::Oracle when calling
> 'execute_array' with UTF-8 NLS...
> From: demer...@gmail.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; blan...@worldcom.ch; dbi-dev@perl.org
>
> On 9 October 2012 14:29, John Sco
th UTF-8 NLS...
> From: demer...@gmail.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; blan...@worldcom.ch; dbi-dev@perl.org
>
> On 9 October 2012 14:29, John Scoles wrote:
> >
> > I am sort of with Martin on this one as we would like to know why?
> >
I am sort of with Martin on this one as we would like to know why?
At first glace decrementing the reference count like this would not seem to be
a little overkill as tuples_utf8_av is created with newAV() which should take
care of that for us.
However looking a little deeper maybe we need to
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-dev@perl.org
> > CC: dbi-us...@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-dev@perl.org
ijn Brand and Charles Jardine for those.
Please enjoy.
John Scoles
On 18/02/2011 4:12 AM, Charles Jardine wrote:
Ok that cleans that one up..
Hopefully I will have some time today to get to that one
Thanks
John
On 17/02/11 12:34, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
http://www.pythian.com/news/wp-content/uploa
On 17/02/2011 7:34 AM, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
You need to work on longdouble support I guess
Here's a patch to make the test PASS on all systems, but I'm not s
On Wed, Feb 16, 2011 at 5:45 AM, Martin J. Evans
wrote:
> On 11/02/11 18:43, John Scoles wrote:
>>
>> Here is the latest and greatest DBD::Oracle for your programming pleasure.
>>
>> You can find the Zip file here
>>
>> > href="http://www.pythian.c
.$record."END;"
);
That might do the trick.
Without seeing the original SQL it will be hard to give you a 100%
answer.
Cheers
John Scoles
I'm sorry in advance
if this is not the
correct forum/mechanism to ask this question -
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
ue, Feb 01, 2011 at 09:02:26PM +, Martin J. Evans wrote:
On 01/02/2011 20:50, Tim Bunce wrote:
On Tue, Feb 01, 2011 at 10:58:14AM -0500, John Scoles wrote:
My only concern is when it does error (no matter what the setting of
AutoCommit) you always get unef;
Umm, yes. Returning undef (or an empt
On 02/02/2011 7:15 AM, Tim Bunce wrote:
On Tue, Feb 01, 2011 at 09:02:26PM +, Martin J. Evans wrote:
On 01/02/2011 20:50, Tim Bunce wrote:
On Tue, Feb 01, 2011 at 10:58:14AM -0500, John Scoles wrote:
My only concern is when it does error (no matter what the setting of
AutoCommit) you
On 01/02/2011 11:04 AM, Martin J. Evans wrote:
On 01/02/11 15:50, John Scoles wrote:
On 01/02/2011 10:44 AM, Tim Bunce wrote:
On Sun, Jan 30, 2011 at 05:46:49PM +, Martin J. Evans wrote:
push @$tuple_status, [ $sth->err, $sth->errstr, $sth->state ];
so I guess the p
On 01/02/2011 10:48 AM, Tim Bunce wrote:
On Mon, Jan 31, 2011 at 08:39:40PM +, Martin J. Evans wrote:
I imagine most DBDs [if not all] that implement execute_array
[Just a reminder that drivers can opt to implement just
execute_for_fetch() and use the DBI's default execute_array() method,
On 01/02/2011 10:44 AM, Tim Bunce wrote:
On Sun, Jan 30, 2011 at 05:46:49PM +, Martin J. Evans wrote:
push @$tuple_status, [ $sth->err, $sth->errstr, $sth->state ];
so I guess the pod should say:
"If the execution of a tuple causes an error, then the corresponding status
array
One other thing I was picking up on is the case if you have
autocommit on and RaiseError off
I this case it if there was a an error while running in list mode it
will allways return undef. Where looking at the spec one might expect
to see undef and XX which would be the # ot records effected?
A
This behaviour is also inconsistent with versions of Oracle 11. Some
patch sets show it other do not.I will have an answer for if later today
Did you try it with the full 11 client.
Cheers
John
On Fri, Jan 21, 2011 at 6:02 AM, Martin J. Evans
wrote:
> On 20/01/11 09:55, Tim Bunce wrote:
>
>
On 20/01/2011 12:20 PM, Martin J. Evans wrote:
On 20/01/11 12:31, John Scoles wrote:
On 19/01/2011 5:25 PM, Martin J. Evans wrote:
Great stuff Martin I am sure we can clear this up.
One thing I did notice was you never set the 'ora_array_chunk_size' which is
defaulting to 1000
On 20/01/2011 9:16 AM, Brian Phillips wrote:
On Dec 1 2010, 9:59 am, sco...@pythian.com (John Scoles) wrote:
It will be in 1.28 as 1.27 is reserved for now.
Look for it in the next few weeks
Any idea when 1.28 will be released?
I want to have it out by the end of the Month.
Remind me
On 19/01/2011 5:25 PM, Martin J. Evans wrote:
Great stuff Martin I am sure we can clear this up.
One thing I did notice was you never set the 'ora_array_chunk_size'
which is defaulting to 1000
I wonder if running this with this value set to say 2 or 3 will see a
change in behaviour.
No do
On 19/01/2011 6:47 AM, Tim Bunce wrote:
As usual very sage advice Tim.
I'm sorry to arrive here late. Seems I've been missing all the fun!
Some observations:
- I think it's reasonable for execute_array() and execute_for_fetch()
to return an error (ie err() true and so trigger RaiseError
On 18/01/2011 9:47 AM, Martin J. Evans wrote:
On 18/01/11 14:11, John Scoles wrote:
On 18/01/2011 8:35 AM, Martin J. Evans wrote:
John,
I slightly reformatted you reply as you added comments on the end of lines I
wrote which made it look like I said them.
On 18/01/11 12:40, John Scoles
On 18/01/2011 9:47 AM, Martin J. Evans wrote:
Just as a Side note seems execute_array was added well after the first
DBI spec was written.
DBI 1.24,4th June 2002 seems to be the correct date rather a late
addition.
Cheers
John
On 18/01/11 14:11, John Scoles wrote:
On 18/01/2011 8
On 18/01/2011 9:47 AM, Martin J. Evans wrote:
On 18/01/11 14:11, John Scoles wrote:
On 18/01/2011 8:35 AM, Martin J. Evans wrote:
John,
I slightly reformatted you reply as you added comments on the end of lines I
wrote which made it look like I said them.
On 18/01/11 12:40, John Scoles
On 18/01/2011 8:35 AM, Martin J. Evans wrote:
John,
I slightly reformatted you reply as you added comments on the end of lines I
wrote which made it look like I said them.
On 18/01/11 12:40, John Scoles wrote:
On 17/01/2011 3:34 PM, Martin J. Evans wrote:
There appear to be differences
On 18/01/2011 7:52 AM, H.Merijn Brand wrote:
On Tue, 18 Jan 2011 07:40:25 -0500, John Scoles
wrote:
On 17/01/2011 3:34 PM, Martin J. Evans wrote:
There appear to be differences between DBDs which do not handle
execute_array (so DBI does it for them) and DBDs which do handle
execute_array
On 17/01/2011 3:34 PM, Martin J. Evans wrote:
There appear to be differences between DBDs which do not handle
execute_array (so DBI does it for them) and DBDs which do handle
execute_array (e.g., DBD::Oracle). The main ones discussed on
#dbix-class which I investigated are whether the driver s
On 14/01/2011 10:21 AM, Martin J. Evans wrote:
On 14/01/11 15:01, H.Merijn Brand wrote:
On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans"
wrote:
On 14/01/11 14:30, H.Merijn Brand wrote:
Maybe this is a feature request, but if I have
ORACLE_USERID=john/sekrit
DBI_USER=pablo
DB
On 14/01/2011 9:30 AM, H.Merijn Brand wrote:
Maybe this is a feature request, but if I have
ORACLE_USERID=john/sekrit
DBI_USER=pablo
DBI_PASS=neruda
I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of*
the ORACLE_USERID. Anyone can come up with a good reason why this
Ok I got it to work 100% with the test seems you gave a little too much SP
You will find it in trunk of DBD::Oracle
which is here
http://svn.perl.org/modules/dbd-oracle/trunk
Thanks again
Cheers
John Scoles
On Tue, Dec 14, 2010 at 10:39 AM, Tim Oertel wrote:
>
> Hi,
>
> We w
I have applied this patch to trunk you can find it here
http://svn.perl.org/modules/dbd-oracle/trunk
It will be part of Release 1.28 sometime before the end of the month.
Cheers
John Scoles
On Tue, Nov 16, 2010 at 10:28 AM, Jan Pazdziora wrote:
>
> Hello,
>
> The DBD::Orac
So in a nutshell 1.27 is a single issue maintenance release.
For those interested in the whole story you can have a look at this thread
http://www.nntp.perl.org/group/perl.dbi.dev/2010/08/msg6217.html
Any an all testing with differing Perls would be much appreciated
Cheers John Scoles
should be out soon
Cheers
John Scoles
On 14/12/2010 10:39 AM, Tim Oertel wrote:
Hi,
We were recently trying to pass an array to a stored procedure.
It worked fine the first call, but subsequent calls were receiving
the wrong array size, and with old array entries.
After some investigation, it
On 01/12/2010 9:22 AM, Brian Phillips wrote:
On Nov 30, 8:37 am, sco...@pythian.com (John Scoles) wrote:
Just wanting to make sure this doesn't get lost in the shuffle...
Depends is it a specific OS patch for DBD::Oracle or a general one DBI?
I am keeping an eye on it.
I'm not sur
On 30/11/2010 10:28 AM, Tim Bunce wrote:
On Mon, Nov 15, 2010 at 10:04:56AM -0800, Brian Phillips wrote:
- DBD::Oracle::db::_login($dbh, $dbname, $user, $auth, $attr)
- or return undef;
+{
+my @local_signals = @{ $attr->{ora_local_signals} || [] };
+local @s.
On 30/11/2010 9:28 AM, Brian Phillips wrote:
On Nov 15, 12:04 pm, bpphill...@gmail.com (Brian Phillips) wrote:
See below for a patch that does not change the default behavior but
allows the user to specify a list of signals to be localized during
the connect phase. This could easily be default
On 15/11/2010 9:15 AM, Brian Phillips wrote:
On Nov 9, 9:43 am, bpphill...@gmail.com (Brian Phillips) wrote:
In my opinion, adding an option to change the current behavior is low
risk and completely satisfactory for resolving my issue while leaving
current behavior unchanged. If there are conc
drivers that have been
around for a while (like DBD::Oracle) may break!!
Check out this thread
http://www.nntp.perl.org/group/perl.dbi.dev/2010/08/msg6217.html
for the long version
I am announcing this on dbi-users as well to expand the group of people
who may be using 5.13.3.
Cheers
John Scoles
On 11/2/2010 2:49 PM, Brian Phillips wrote:
Hello - I recently discovered that when we do a DBI->connect to an Oracle
database, the process no longer responds to SIGINT signals. I'm not sure if
it's something in DBD::Oracle (I can't find anything messing with $SIG{INT})
or something in the Oracl
is much easier then trying to
pick them all out yourself or by recompiling and fixing as you go.
Cheers
John Scoles
file_PL_vars.pl
Description: Perl program
On 10/25/2010 1:52 PM, Martin J. Evans wrote:
On 25/10/2010 18:57, John Scoles wrote:
On 10/25/2010 1:42 PM, Martin J. Evans wrote:
On 25/10/2010 18:04, John Scoles wrote:
On 10/25/2010 10:33 AM, Tim Bunce wrote:
On Mon, Aug 30, 2010 at 07:28:31AM -0400, John Scoles wrote:
Tim Bunce wrote
On 10/25/2010 1:42 PM, Martin J. Evans wrote:
On 25/10/2010 18:04, John Scoles wrote:
On 10/25/2010 10:33 AM, Tim Bunce wrote:
On Mon, Aug 30, 2010 at 07:28:31AM -0400, John Scoles wrote:
Tim Bunce wrote:
Looks like DBD::Oracle as PERL_POLLUTE as well.
Lucy!!! You have some renaming to do
On 10/25/2010 10:33 AM, Tim Bunce wrote:
On Mon, Aug 30, 2010 at 07:28:31AM -0400, John Scoles wrote:
Tim Bunce wrote:
Looks like DBD::Oracle as PERL_POLLUTE as well.
Lucy!!! You have some renaming to do!!!
A project of 1.26 perhaps
As 5.13.x comes closer to being 5.14 this issue is
ote:
> On Wed, 15 Sep 2010 10:35:03 -0400, John Scoles
> wrote:
>
> > Ok here I am again for the fourth time :(
> >
> > You can find it here
> >
> > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC4.tar
>
> Please use the correct extension:
??
Please Enjoy
John Scoles
s it was a typo on my part. As well got
rid of some harmless compiler warnings
Cheers
John Scoles
--
The best compliment you could give Pythian for our service is a referral.
Tim Bunce wrote:
Looks like DBD::Oracle as PERL_POLLUTE as well.
Lucy!!! You have some renaming to do!!!
A project of 1.26 perhaps
cheers
John
Short version:
Please download build test *and install* DBI 1.613_71, then download build
and test any compiled drivers you use to check they work wi
,is_initp );\
Hopefully that will get it
Cheers
John Scoles
John Scoles wrote:
Well story two of the 'two bit' version of DBD::Oracle 1.25
You can find release candidate 2 here
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC2.tar.gz
This one has some minor ch
y.t line 45
> STORE in DBD::Test::db ('DBI::db=HASH(0x1fe033c)'
'AutoInactiveDestroy' 1) []
< STORE= 1 at ./t/16destroy.t line 46
< connect= 'DBI::db=HASH(0x1a45934)' at ./t/16destroy.t line 120
> FETCH in DBD::Test::db ('DBI::db=HASH(0x1f
David E. Wheeler wrote:
now we are getting
t/zvp_16destroy.t(Wstat: 0 Tests: 18 Failed: 0)
Parse errors: Bad plan. You planned 20 tests but ran 18.
t/zvxgp_16destroy.t (Wstat: 0 Tests: 18 Failed: 0)
Parse errors: Bad plan. You planned 20 tests but ran 18.
Files=171, Tests=6280,
:db=HASH(0x1a457c4)' at ./t/16destroy.t line 118
> FETCH in DBD::Test::db ('DBI::db=HASH(0x1fe0234)'
'AutoInactiveDestroy') []
< FETCH= 1 at C:/Perl/lib/Test/More.pm line 292
> FETCH in DBD::Test::db ('DBI::db=HASH(0x1fe0234)' 'Active'
David E. Wheeler wrote:
Fellow DBIers,
With a bit of help from me, Tim added a new feature to the DBI yesterday:
AutoInactiveDestroy. I wrote the test for it. The test, however, forks. We need
to make sure that it doesn't die an ugly death on systems without fork (and on
Win32, where it's emu
Make sure you double check the MANIFEST if that is important for you
system. I have yet to make sure it is 100% complete yet.
Jens Rehsack wrote:
2010/7/23 John Scoles :
Well story two of the 'two bit' version of DBD::Oracle 1.25
You can find release candidate 2 here
http://sv
yself.
and hopefully I got rid of the warning error in the .xs file for
OCILobLocatorIsInit_log_stat
And of course the usual bunch of POD changes.
Cheers
John Scoles
--
New! Learn why & how to love your data with Pythian's new webinar series.
Topics, details & register: http://www.pythian.com/webinars
t; On Fri, 2010-07-16 at 13:04 -0400, John Scoles wrote:
> > John Scoles wrote:
> >
> > Nobody wants to play with my new toy?
> >
>
> I will, waiting for our dba to setup the DRCP for me.
>
> > :(
> >
> > > Well it is finally here the 'two b
John Scoles wrote:
Nobody wants to play with my new toy?
:(
Well it is finally here the 'two bit' version of DBD::Oracle 1.25
You can find the release candidate here
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC1.tar.gz
Any and all testing will be most welcome
Connection
Pool) if you happen to be using 11g or later
As well 'get_info' has been greatly expanded
Plus the the usual hodgepodge of bug fixes detailed below
Added support for the OCIPing by John Scoles
Spell checked the pod (the first time in a while me thinks) updated the
todo By
names rather than POOL.
as well I made ORA_DRCP_CLASS an optional value. Some users my not want to
use it.
Thanks again
John Scoles
On Wed, Jul 7, 2010 at 4:34 PM, luben karavelov wrote:
> As I have promissed, here comes the documentation patch. I am not native
> speeker, so may be i
uot;; does not return the correct length when used with DRCP
If you have half a moment and can take a look at that one that would be
great.
Cheers
John Scoles
Best regards
luben karavelov
opps didn't see the patch attachment.as it was hidden until I looked for it
(stupid google mail)
That should work as it is only on the perl side.
Thanks Martin
On Fri, Jun 18, 2010 at 8:53 AM, Martin Evans wrote:
> John Scoles wrote:
> > The way Ping works is different is de
The way Ping works is different is depending on the version of DBD::Oracle
you are using. Which version of DBD::Oracle are you using??
cheers
John Scoles
On Thu, Jun 17, 2010 at 2:34 PM, Thomas M. Payerle wrote:
> Hi,
>
> My colleagues and I encountered a problem in some code which s
On Tue, Jun 8, 2010 at 7:31 AM, Tim Bunce wrote:
> On Mon, Jun 07, 2010 at 09:52:52PM +0200, H.Merijn Brand wrote:
> > On Mon, 07 Jun 2010 13:51:26 -0400, John Scoles
> > wrote:
> >
> > Summary:
> >
> > ☑ unicode => Unicode
> > ☐ DBDs
H.Merijn Brand wrote:
On Mon, 07 Jun 2010 13:51:26 -0400, John Scoles
wrote:
H.Merijn Brand wrote:
For my own projects (which includes two DBD's), I have been working on
spell-check issues. I'm not born in an English-speaking country, nor
was I raised in one, so I m
H.Merijn Brand wrote:
For my own projects (which includes two DBD's), I have been working on
spell-check issues. I'm not born in an English-speaking country, nor
was I raised in one, so I make errors. Probably quite a few.
spell-checkers help a lot, but most work on en_US, not en_EN, and I try
t
Had a quick look at it today give it a try agian but this time make sure you
have autocommit off
AutoCommit=>1
on the connection method
cheers
On Fri, May 21, 2010 at 11:20 AM, John Scoles wrote:
> Ok I guess it is back to square 1 on this.
>
> Unfortunetly no time to look
:
John Scoles wrote:
Ok I have patched up a solution I think will work across the board and you
can find it here
http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
here are the details
ora_oci_batch
For 11g users you may encounter an error while using the execute_array in
that it
can use at the OS level to set this
value. It can also be set as an attribute on both the Connect and Prepare.
Unfortunately I can't test it (do not have an 11g box yet) so It will stay
in the above branch until it is tested hopefully by you Scott
Cheers
John Scoles
--
See Pythian's Ale
uld you want to get their
values??
> > if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
> > DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
> ora_oci_err_mode);
>
> I don't understand why you need it in ora_s
mance.
You will have to ask Tim Bunce or maybe Alligator Descartes for that
change but I do not see any use in having it.
A statement handle without 'SQL' ( a statement) would be meaningless,
something like a sentence with only punctuation.
cheers
John Scoles
With best regard
simple enough I will put it in the 1.25 release
I created this patch because of this issue (which we have run into),
==
Parameter Description
line Returns a single line of buffered information,
Great looks like a release on Monday
cheers
John Scoles
wrote:
Horray.
Just one more thing has come up in like the last 15min
can you redo your the make test with the following file
http://svn.perl.org/modules/dbd-oracle/trunk/ocitrace.h
It is a trivial change but just want to make
OCIDateTimeToText to 6 instead of 0 for
varrays of timestamps
needed to conduct a large scale experiment of some sort
cheers
John Scoles
Charles Jardine wrote:
On 28/01/10 15:59, John Scoles wrote:
Well here comes the big #5
It can be found at the usual place
http://svn.perl.org/modules/dbd
Well here comes the big #5
It can be found at the usual place
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.24-RC5.tar
This time round was a patch to fix a patch for some warnings that was
causing a seg-fault on some 32 bit boxes
Cheers
and thanks for all the testing
John
Well here comes #4
It can be found at the usual place
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.24-RC4.tar
This time round I added a little patch from Charles Jardine fro objects
and some fixes for warnings
I have changed the ora_ncs_buff_mtpl default value back to 4 so it
might have to make it 2 to cover
more bases.
cheers
John Scoles
Martin Evans wrote:
John Scoles wrote:
Thank Charles that is really good stuff
I have not investigated the
NLS_LANG=.WE8ISO8859P1, but the tests 30long.t and 31lob_extended.t
still fail badly if NLS_LANG=.AL32UTF8.
bug yet as
d.t
and send me the results I will have something more to go on.
Look for another RC in the next day or two.
Cheers
Jardine wrote:
On 14/01/10 12:19, Charles Jardine wrote:
On 12/01/10 12:07, John Scoles wrote:
Ok third time is a Charm
The Third RC of the beer edition of DBD::Oracle 1.2
Ok third time is a Charm
The Third RC of the beer edition of DBD::Oracle 1.24 can be found at
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.24-RC3.tar
This round has a few little patches from Martin Evans on it.
Please test and enjoy
Cheers
John Scoles
Well here it is the second crack at 1.24 Beer version of DBD::ORACLE
You can find the release candidate here
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.24-RC2.tar
this time out I have hopefully fixed most of the warnings
I have also updated the pod to explain what ora_ncs_bu
Patch to add support for a few
Oracle data types to type_info_all from David Hull
Added from rt.cpan.org Ticket #=49435 Patch to add support for a few
Oracle data types to dbd_describe from David Hull
Fix for rt.cpan.org Ticket #=49331 Bad code example in POD from John
Scoles
Added
Ok that will be the next one to get done
thanks
Jan Mach wrote:
We have published len_char_size property of statement handle. Why? That's
because of nvarchar type.
You have column nvarchar(20) and you get length 40 using PRECISION (it's
right because is BYTE length). But we need for our applic
Of you could give it a try on 64 bit power solaris it you want to tug
all of your hair out.
H.Merijn Brand wrote:
On Fri, 27 Nov 2009 10:41:19 -0400, Ralph Doncaster
wrote:
On 11/27/09, H.Merijn Brand wrote:
On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster
wrote:
While you're a
1 - 100 of 195 matches
Mail list logo
