I'm writing a perl script that reads the source of a PL/SQL package from a
file, pre-processes it, optionally wraps it (using Oracle's wrap utility),
and then executes it in the DB.
If I don't wrap the file, everything works fine. However, if I do wrap it, I
get the following error from the
I've subsequently tried this on DBI 1.30, DBD::Oracle 1.12, Perl 5.8 and
Oracle 9.2. Unfortunately I get the same error :-(
I've also tried the dbh-do() method (clutching at straws). Same again.
Steve
On Tuesday 22 October 2002 11:25, Steve Baldwin wrote:
I'm writing a perl script
$packageText;
print SQLSESSION /\n;
print SQLSESSION \nexit\n;
print SQLSESSION \n;
close (SQLSESSION);
Or you could upgrade your DBI and DBD.
-Chris
-Original Message-
From: Steve Baldwin [mailto:stbaldwin;multiservice.com]
Sent: Thursday, October 24, 2002 3
I didn't hear any response on this. Can anyone please help me ?
Thanks,
Steve
-- Forwarded Message --
Subject: Creating wrapped PL/SQL packages using DBI
Date: Tue, 22 Oct 2002 11:25:24 +1000
From: Steve Baldwin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I'm writing a perl
How about :
Select to_char(actual_date, '-Q'), sum (value) from daily_data
Where sensor_id=?
Group by to_char(actual_date, '-Q')
Couldn't you have the to_char format mask as a bind variable ?
Steve
-Original Message-
From: Fong, Anna [mailto:anna;water.ca.gov]
Sent: Friday, 15
Hi,
I'm trying to build DBD::Oracle 1.12 on the latest cygwin, and perl 5.8
- without much success. I have Oracle 9.2 installed on the XP side of
my machine, and have verified it is functional. I can run sql*plus from
cygwin (if that proves anything). Every other Perl module (including
DBI)
, 19 November 2002 2:30 AM
To: [EMAIL PROTECTED]; Steve Baldwin
Subject: Re: Building DBD::Oracle on cygwin
On Mon, 18 Nov 2002 20:26:05 +1100 Steve Baldwin
[EMAIL PROTECTED] wrote:
I'm trying to build DBD::Oracle 1.12 on the latest cygwin, and perl
5.8
- without much success. I have Oracle
Actually, because José mentioned he was doing an insert in his function,
it cannot be called from SQL, but only from an anonymous PL/SQL block.
In any instance, it is *always* faster to execute a PL/SQL function from
an anonymous PL/SQL block than from a SELECT.
In terms of the throughput you are
it limited my ability to have multiple Oracle
Home's.
Thanks,
Steve
-Original Message-
From: Steve Baldwin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 19 November 2002 6:53 AM
To: 'Michael A Chase'; [EMAIL PROTECTED]
Subject: RE: Building DBD::Oracle on cygwin
Thanks for that Michael. My
Here's what worked for me ...
Platforms
Windows XP Pro
Cygwin 1.3.15-2 (including Perl 5.8.0)
I have installed the following Oracle products :
Oracle 9i Database 9.2.0.1
Oracle Net Listener 9.2.0.1
Oracle Database Utilities 9.2.0.1
Oracle Verify
The answer (I'm pretty sure) is 'Yes'. Check out the statement handle
method bind_param_inout in the DBI documentation.
-Original Message-
From: Carlos Barroso [mailto:[EMAIL PROTECTED]]
Sent: Friday, 22 November 2002 7:51 PM
To: [EMAIL PROTECTED]
Subject: in and out parameters
Hy
Can someone please tell me if the RowCacheSize needs to be set before
calling 'prepare' or before calling 'execute' if I want it to be
effective for a SELECT statement. I'm using Oracle, so I know it is
supported, but the RowsInCache statement handle attribute returns undef,
so it's difficult to
, but then we're also using Oracle 7.3, which is even older :-)
Cheers,
Steve
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 28 November 2002 11:41 AM
To: Steve Baldwin
Cc: [EMAIL PROTECTED]
Subject: Re: RowCacheSize - when to set ?
Set before prepare. Use trace
I'm sure this has been asked many times before, but Tim's reply here
prompted me to ask again. Is there any way to access the DB version (as
per your example of get_info(18) below) from DBI. For example as an
attribute of the database handle. I've consulted the manual, but
couldn't find any
I am getting the following error on disconnect ...
DBI::db=HASH(0x104dd094)-disconnect invalidates 1 active statement
handle (either destroy statement handles or call finish on them before
disconnecting) at yyy line xxx
Is there any way of finding out *which* statement handle is active.
This
PROTECTED]]
Sent: Friday, 3 January 2003 10:27 PM
To: Steve Baldwin
Cc: [EMAIL PROTECTED]
Subject: Re: Detecting active statement handles
snip
Use trace and see which DBI::st objects get DESTROY'd after the
disconnect.
Tim.
How about simply displaying the {Statement} attribute in the message.
At least that would assist in tracking it down.
Do you think that would be easier to code ?
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 4 January 2003 11:13 AM
To: Steve Baldwin
Cc
I see in the fine manual, the suggested way of interrupting an executing
statement from within a signal handler is to use the cancel function.
Unfortunately, it doesn't give an example of its use. I tried simply
doing DBI-cancel(), but receive the following error :
Can't locate
-
From: Ronald J Kimball [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 29 January 2003 8:17 AM
To: Steve Baldwin
Cc: [EMAIL PROTECTED]
Subject: Re: Calling cancel() from signal handler
On Wed, Jan 29, 2003 at 08:11:43AM +1100, Steve Baldwin wrote:
I see in the fine manual, the suggested way
As far as I am aware, this functionality is not currently supported in
DBD::Oracle.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Saturday, 1 February 2003 4:58 AM
To: [EMAIL PROTECTED]
Subject: Binding for PL/SQL Arrays
I am trying to use perl to call a
If you're using version 9.2.0.2 of the client, you will *not* be able to
connect to Oracle 7.3.x. You will get the following error ...
ORA-24439: Connections to Oracle7 server are no longer supported.
Nice one Oracle !!
P.S. Client 9.2.0.1 seems to work - even though it's not supposed to.
Any clues what would cause this error ...
(in cleanup) DBD::Oracle::db rollback failed: ORA-01001: invalid cursor
(DBD: rollback failed) at ...
Thanks,
Steve
in a (long lasting and) so far
read-only transaction. If there had been any insert/update/delete
operations any required cursors should be valid. cu, Christian
- Original Message -
From: Steve Baldwin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 1:02 PM
Subject: Error
Be aware there are some limitations of DBI::Proxy. From memory it doesn't
support named bind parameters (i.e. :cust_id), so if your app makes
extensive use of them it may be more trouble than its worth.
Other than that, it is very straight forward to set up. Checkout the
perldoc.
-Original
This is not a DBI/DBD::Oracle restriction but an Oracle one. If you try the
same query from SQL*Plus you will get the same error.
If your Oracle version is = 8.1, you could change the data type of XML_TEXT
from LONG to CLOB, in which case your query will work.
Even using a stored procedure is
Ron,
(Apologies for top-posting ...)
In most cases there will be no difference, but it is possible for
trigger based logic to subsequently bump the value of a sequence. This
means fetching seq.currval after the insert could give you a value higher
than the one actually used in the insert.
What
Hi Ron,
See below ...
-Original Message-
From: Ron Savage [mailto:[EMAIL PROTECTED]
Sent: Friday, 7 October 2005 9:09 AM
To: List - DBI users
Subject: RE: Oracle and dbh - last_insert_id
On Fri, 7 Oct 2005 08:24:22 +1000, Steve Baldwin wrote:
Hi Steve
(Apologies for top-posting
Razat,
You must have previously had a different version of the Oracle client.
DBD::Oracle *requires* the SQL*Net client to connect to the DB. If you
installed a later version of the SQL*Net client, you will either need to
re-build DBD::Oracle against that version, or download a version of the
of this list.
Steve
-Original Message-
From: Gupta, Razat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 18 October 2005 8:55 PM
To: Steve Baldwin
Subject: RE: Oracle/DBI
Dear Steve,
Can you please give me a brief description of the steps you want me to
follow.
Like : if I m running Oracle Client 8.1.0
I don't know if this helps, but if you want to insert into a BLOB column,
you can by simply specifying the ora_type attribute. For example ...
use DBD::Oracle qw(:ora_types);
:
my $sth = $dbh-prepare(q(
insert into some_table (blob_col) values (:blob_data)
));
This may not answer your question, but you can incorporate the time format
mask in the call to TO_DATE. For example ...
insert
into history (history_timestamp)
values (to_date(:ts_val, '-MM-DD HH24:MI:SS'))
Steve
-Original Message-
From: Ron Savage [mailto:[EMAIL PROTECTED]
Ron,
The timestamp data type was introduced relatively recently to Oracle, and
has the capacity to store fractional seconds (basically to the resolution of
your OS clock).
Unless you genuinely need fractional seconds, you can use the ordinary old
DATE data type which stores date+time (to the
Hi Robert,
Firstly, it may be just me, but I don't see any DECODE other than in your
opening question. Secondly, the actual error text would be helpful in
diagnosing the problem.
I have used decode many times with DBI and never had a problem.
Steve
-Original Message-
From: Robert
Hi Peter,
You have a valid concern regarding memory usage.
Don't use fetchall_arrayref when you are dealing with such large numbers of
rows. Some DBD's (eg DBD::Oracle) allow you to control the caching on the
client side by setting RowCacheSize (refer to DBI pod). This will give you
adequate
Alternatively you can install DBD::Oracle on the DB server (which will
presumably have all the relevant Oracle bits) and install and use DBD::Proxy
on your client machine.
Even if you use ODBC, you still need the Oracle client underneath it.
Cheers,
Steve
-Original Message-
From:
John,
When you say named parameter binding is not supported, are you talking about
*all* named parameters, or just for array operations? We use named
parameters (e.g. :cust_id) extensively because it is more readable, position
independent, and if you are using the same parameter more than once
You should be able to simply use the function in the SQL within your Perl
script. For example :
my $sth = $dbh-prepare(q(
SELECT my_func(raw_data)
FROMmy_table
));
etc
If you can use the function in SQL*Plus, you can use it with Perl/DBI.
HTH,
Steve
-Original Message-
September 2006 7:40 PM
To: Steve Baldwin
Cc: dbi-users@perl.org
Subject: Re: DBI custom functions
Thanks Steve,
I agree, you can call the function this way, but then you have to be sure
that the function is already defined in Oracle. I was wondering if there
is
a way to define
I've found that PIPELINED functions work really well. From Perl you simply
say something like :
my $sth = $dbh-prepare(q(
SELECT *
FROM TABLE(mypipeline_function)
));
Steve
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent:
I'm using the current versions of DBI and DBD::Oracle. Is it possible
to limit the number of rows returned by fetchall_xxx ? Basically, I
want to retrieve up to (say) 200 rows, but utilise an array fetch, so
only making round trip to the database. I know OCI supports this, but
can't see
Here's what happens in SQL*Plus (both 9i and 73)
As you can see, SQL*Plus preserves trailing spaces
SQL*Plus: Release 90100 - Production on Fri Mar 1 08:45:40 2002
(c) Copyright 2001 Oracle Corporation All rights reserved
Connected to:
Oracle9i Enterprise Edition Release 90100 - Production
You could try setting the RowCacheSize to something like 500, so the
round trips to the DB are reduced, and it effectively does array
fetches. This is covered (I think) in the DBI POD.
Chris Starling wrote:
First question: Is there a DBD::Oracle specific mailing list I should
be posting
This is usually indicative of an Oracle error - i.e. a bug in Oracle is
causing your application to terminate on a signal (eg SEGV). Have you
had a look in the alert log and/or the 'udump' directory to see if there
is a dump from your process ? If this is happening 'all of a sudden' I
would
You may be able to use the explain plan functionality in Oracle to
obtain the tables participating in a SELECT statement.
Steve
On Wed, 2008-05-07 at 12:48 -0700, Jonathan Leffler wrote:
On Wed, May 7, 2008 at 12:37 PM, Lamb Joseph [EMAIL PROTECTED] wrote:
To answer you question, for an
I've just noticed an apparent regression/change_of_behaviour that
affects me.
We do a good deal of our DB access accessing tables via private
synonyms. That is, we connect via schema_X which has a private synonym
(lob_table) to schema_Y.lob_table.
On our 'current' machines which have
to have another look at this, I would be
most grateful.
Cheers,
Steve
On Tue, 2008-08-05 at 14:24 +1000, Steve Baldwin wrote:
Hi,
The problem that existed for CLOB's and BLOB's in 1.21 has been
partially fixed. The good news is that CLOB's appear to be OK.
BLOB's however appear to still
time is down to only a
few hours a week for the next little while. I have worked this one up
but I cannot seem to recreate the error but I am still working onit.
It it is on my list for 1.23
Cheers
John Scoles
Steve Baldwin wrote:
John,
Now that you are back from vacation (I
24 in '
insert
into*sb_blob_x (id, bcol)
values (:id, :blob)
')' (err#0)
- trace= 3 at blob.plx line 51 via at blob.plx line 0
On Tue, 2008-09-09 at 07:00 -0400, John Scoles wrote:
Yes and I get no error with it it seems to run fine.
Steve Baldwin wrote:
Thanks
my code against a 10.2 DB looks like you are using 9.2??
perhaps you patch-set for you 9.2 db is not up to date??
cheers
John Scoles
Steve Baldwin wrote:
I wonder what we have different. Here's a run I just did that shows
Oracle version, DBI version, and DBD::Oracle version
Martin,
Personally I would use a global temporary table in this scenario.
However if that is considered offensive or morally dubious, you could do
something like :
package pkg1
type t1 is table of mytable%rowtype index by binary_integer
g_tt1
g_ipls_integer
function f1 return
I believe Martin was referring to the Oracle trace files. These will be
on your database server. Check with your DBA if you're not sure where
they live.
Steve
On Tue, 2008-10-28 at 10:32 -0400, Carl Furst wrote:
Thanks for the reply! I appreciate the help. I don't suppose you would know
All,
A part of on of our applications has just started failing with this :
OCI-21500: internal error code, arguments: [kghssgai5], [4080],
[293722940], [24], [], [], [], []
��t7��t7��t7
We are using an 11i client connecting to a 9.2.0.8 instance. Our OS is
Red Hat Enterprise 5, our version of
grateful.
Steve
On Mon, 2008-11-10 at 13:29 +1100, Steve Baldwin wrote:
All,
A part of on of our applications has just started failing with this :
OCI-21500: internal error code, arguments: [kghssgai5], [4080],
[293722940], [24], [], [], [], []
��t7��t7��t7
We are using an 11i client
at err.plx line 33
Errors in file :
OCI-21500: internal error code, arguments: [kghssgai5], [4080],
[70521780], [24], [], [], [], []
��t7��t7��t7Aborted
Hope this helps some other knucklehead ...
Steve
On Mon, 2008-11-10 at 19:12 +1100, Steve Baldwin wrote:
Just a follow up. It may
I echo Tim's comments. We looked into implementing auto reconnect for
our applications (e.g. in the case of the DB going down) and unless you
have a *very* simple scenario it was just too much work to save and
restore state.
For example, you could lose the connection between a -prepare and an
Hi,
We have found some of our code that worked perfectly well with 9i
started failing when we moved the database to 11g. We are using
DBD::Oracle 1.22.
I have managed to create a very simple test case ...
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw();
my $uidpwd = 'usr/p...@db';
Thanks for the quick response John.
We are running 11.1.0.7. As far as I am aware it is up to date
patch-wise. I'm at home at the moment and won't be in the office for
about 3 hours (UTC+11). I'll run the make test then. Do you want me to
run it before the patch, after, or both?
Cheers,
DBI version : 1.605
DBD::Oracle version : 1.22
Database: 11.1.0.7 (don't think this matters)
DB Charset : AL32UTF8 (this definitely matters)
NLS_LANG: AMERICAN_AMERICA.AL32UTF8
Consider the following script ...
#!/usr/bin/perl -w
use strict;
use
John,
I installed this version and it didn't seem to make any difference ...
stbald...@au-stb-mobile:~/dev$ ./utf8.plx
Using DBI 1.605 and DBD::Oracle 1.23
Sym (1) = €
Sym (2) = â¬
I see the same behaviour whether I connect to an 11g or 9i database. I
have the 11g oracle client.
Here's a
stuff.
Thanks for your help,
Steve
On Sun, 2009-03-29 at 12:17 +1100, Steve Baldwin wrote:
John,
I installed this version and it didn't seem to make any difference ...
stbald...@au-stb-mobile:~/dev$ ./utf8.plx
Using DBI 1.605 and DBD::Oracle 1.23
Sym (1) = €
Sym (2) = €
I see
Hi John,
Did you make any sense of this?
Thanks,
Steve
On 30/03/2009, at 10:39 AM, Steve Baldwin wrote:
John,
In case it helps, here is a version of my test script that seems to
correctly handle utf-8 chars for bind_param_inout ...
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw
I'm attempting to build DBD::Oracle for the first time on a Mac. Not
much luck so far.
I'm attempting to build using the latest Instant Client. Here's what
happens ...
stbaldwins-macbook-pro:DBD-Oracle-1.22-DQ1QKH root# perl Makefile.PL
Using DBI 1.52 (for perl 5.008008 on
Has no-one got DBD::Oracle 1.22 running on OS/X Leopard?
Steve
On 02/04/2009, at 10:47 AM, Steve Baldwin wrote:
I'm attempting to build DBD::Oracle for the first time on a Mac.
Not much luck so far.
I'm attempting to build using the latest Instant Client. Here's
what happens
Apologies for answering my own post, but I found this :
http://blacka.com/david/2008/11/12/how-to-install-dbdoracle-on-mac-os-x/
It seems to do the job.
Steve
On 04/04/2009, at 7:28 AM, Steve Baldwin wrote:
Has no-one got DBD::Oracle 1.22 running on OS/X Leopard?
Steve
On 02/04/2009
Hi,
I have a program that worked fine under DBI 1.52 and DBD::Oracle
1.22. Moving to the latest DBI 1.607 but the same DBD::Oracle, I get
a bind error.
Here's a sample program :
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw();
use DBD::Oracle;
sub p{
printf @_;
print
Any comments/feedback on this?
On 09/04/2009, at 11:43 AM, Steve Baldwin wrote:
Hi,
I have a program that worked fine under DBI 1.52 and DBD::Oracle
1.22. Moving to the latest DBI 1.607 but the same DBD::Oracle, I
get a bind error.
Here's a sample program :
#!/usr/bin/perl -w
use
help,
Steve
On 14/04/2009, at 6:56 AM, Steve Baldwin wrote:
Any comments/feedback on this?
On 09/04/2009, at 11:43 AM, Steve Baldwin wrote:
Hi,
I have a program that worked fine under DBI 1.52 and DBD::Oracle
1.22. Moving to the latest DBI 1.607 but the same DBD::Oracle, I
get a bind
$stats_report_p.schema_top_n(?))
] at ./no-bind.plx line 21.
Thanks for your help,
Steve
On 14/04/2009, at 6:56 AM, Steve Baldwin wrote:
Any comments/feedback on this?
On 09/04/2009, at 11:43 AM, Steve Baldwin wrote:
Hi,
I have a program that worked fine under DBI 1.52 and DBD::Oracle
1.22
John,
Not sure I get what you're saying here. I'm not actually selecting
from a DB table so there's no opportunity for NCHAR.
Anyway, NCHAR is only typically for where you want to run your DB in 8
bit but have a few tables with utf-8 data. We have our whole DB in
utf-8 (which can store
$stats_report_p.schema_top_n(?))
] at ./no-bind.plx line 21.
Thanks for your help,
Steve
On 14/04/2009, at 6:56 AM, Steve Baldwin wrote:
Any comments/feedback on this?
On 09/04/2009, at 11:43 AM, Steve Baldwin wrote:
Hi,
I have a program that worked fine under DBI 1.52 and DBD::Oracle
1.22
in '
SELECT TO_CHAR(stats_date, 'J')
FROMTABLE(msc$stats_report_p.schema_top_n(*?))
') [for Statement
SELECT TO_CHAR(stats_date, 'J')
FROMTABLE(msc$stats_report_p.schema_top_n(?))
] at ./no-bind.plx line 21.
Thanks for your help,
Steve
On 14/04/2009, at 6:56 AM, Steve Baldwin wrote
')
FROMTABLE(msc$stats_report_p.schema_top_n(*?))
') [for Statement
SELECT TO_CHAR(stats_date, 'J')
FROMTABLE(msc$stats_report_p.schema_top_n(?))
] at ./no-bind.plx line 21.
Thanks for your help,
Steve
On 14/04/2009, at 6:56 AM, Steve Baldwin wrote:
Any comments/feedback
Have you tried replacing the question marks with named placeholders?
DBD::Oracle supports both and I'm pretty sure you can do an explain
plan with named placeholders.
Steve
On 21/04/2009, at 6:12 AM, E R wrote:
Perhaps I should have divulged more of what I am already trying.
I am
Hi Yannis,
Here's a link I used to install DBD::Oracle using the instant client
on my Mac. I'm using the bundled Perl rather than ActiveState so I'm
not sure if the instructions will still work.
http://blacka.com/david/2008/11/12/how-to-install-dbdoracle-on-mac-os-x/
Anyway, hope it
Probably a silly question, but why do you need two versions of
DBD::Oracle? Can't you build DBD::Oracle against an Oracle client
that is able to connect to both versions? I know the 9i client we
currently use will connect to both 9i and 11g DB instances. I'm
pretty sure a couple of years ago we
I have got DBD::Oracle working on SL. Here's my perl -V ...
bash-3.2# perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level
uname='darwin neige.apple.com 10.0 darwin kernel version
Did you do the 'change NMEDIT' step as per my prev email? I couldn't
get it to build without doing that.
Steve
On Wed, Nov 18, 2009 at 7:07 AM, Jonas Brømsø Nielsen jona...@gmail.com wrote:
Hi John,
Here you go,
###
From the generation of the Makefile:
_kpudbcx
_kpudc
_kpudcx
_kpuddb
_kpudex
_kpudsc
_kpuexes
_kpugbccx
_kpugbncx
_kpugc
_kpugdcx
_kpugml
_kpuic
_kpuicx
_kpulsc
_kpumcf
_kpusdl
_kpusdt
_kpusnchr
_kpusvar
_main
On 17/11/2009, at 21.20, Steve Baldwin wrote:
Did you do the 'change NMEDIT' step as per my prev email? I
Have a look in $ORACLE_HOME/perl/lib/
If you want to use this version (and it will be pretty old), you will
need to either specify the directory containing DBI.pm with the -I
command line arg, or set PERL5LIB to include that directory.
Hope this helps.
Steve
On Tue, Apr 6, 2010 at 9:47 PM,
We're using Apache::DBI and running into problems with Apache child
processes not releasing locks. My current theory for how this happens
goes something like this ...
(Our DB is Oracle if that's relevant)
script issues an update which is successful, and locks the updated row
does other stuff
There's no reason you can't use bind_param_inout for arguments to a
procedure - I do it all the time. Did you encounter any specific
problem?
-Original Message-
From: Galbraith, Mark [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 30 July 2003 7:06 AM
To: [EMAIL PROTECTED]
Subject: Getting
I was intending to use ALTER SESSION SET NLS_TERRITORY='GERMANY' to
allow me to subsequently use the G and D formatting characters in a
TO_CHAR format string. For example
SELECT TO_CHAR (Invoice_Total, '999G999G999D') from ...
However, once I issue the ALTER SESSION, *all* numeric values
Look through the perldoc for LongReadLen. AFAIK, the only limitation is
on memory issued by the OS. A word of warning - if you set LongReadLen
to something large, you should probably set RowCacheSize to 1.
-Original Message-
From: Peter Gibbons-MDG [mailto:[EMAIL PROTECTED]
Sent:
Baldwin
Subject: Re: DBD::Oracle - NLS and numbers
W licie z pon, 04-08-2003, godz. 03:46, Steve Baldwin pisze:
I was intending to use ALTER SESSION SET NLS_TERRITORY='GERMANY' to
Have You tried:
ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '. '
after setting NLS_TERRITORY to 'Germany'?
Waldemar
.
Steve
-Original Message-
From: Waldemar urowski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 12 August 2003 12:19 PM
To: Steve Baldwin
Subject: RE: DBD::Oracle - NLS and numbers
W licie z wto, 12-08-2003, godz. 16:37, Steve Baldwin pisze:
Thanks for the response Waldemar. Actually
Are you sure the Oracle schema/password you are using in your Perl
script is the same one you used to successfully execute the query. It
sounds like a permissions/privileges problem to me. What you are trying
to do is definitely possible in Perl/DBI - I do it in many places with
Oracle versions
it with a schema name, Oracle will attempt to find
the object (in this case the function) in the current schema.
Steve
-Original Message-
From: Gauthier, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 27 August 2003 12:59 PM
To: Steve Baldwin; [EMAIL PROTECTED]
Subject: RE: Using stored PL/SQL
We have a setup here where you cannot connect as sysdba via SQL*Net.
Maybe that's your problem.
-Original Message-
From: Baras, Gal [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 9 September 2003 7:44 AM
To: 'Gold, Samuel (Contractor)'
Cc: '[EMAIL PROTECTED]'
Subject: RE: ORA-01031 when trying
I'm not sure whether this is a DBD::Oracle bug or a bug in the Oracle
client libs, but it only seems to manifest in Perl scripts running on
machines with Oracle client 9.2. The problem is when you have bind
variables that are being bound using bind_param_inout, but those
variables never get
No solution, just an observation ...
It looks as though the -q32 is a compiler flag recognized by the 'xlc'
complier, but the step that fails is a link, and it appears that -q64
(in fact -q anything) is not recognized by the linker.
-Original Message-
From: [EMAIL PROTECTED]
Did you try executing your Perl CGI script from the command line (as
opposed to via the web server) ? None of our CGI scripts set
LD_LIBRARY_PATH, (although we use Apache 1 not 2). Could it be a
permissions thing ? Did you confirm that the Oracle client library is
present and accessible ? If
Would standard Oracle replication not do it for you ?
-Original Message-
From: Ian Harisay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 17 December 2003 8:43 AM
To: [EMAIL PROTECTED]
Subject: Refreshing a database from another
Hi,
I know this isn't the right place to post the message,
Do you really need to execute your commands via SQL*Plus ? Many of the
things you can do in SQL*Plus you can do using DBI. If you definitely
need SQL*Plus, here are a couple of ways of using it ...
(fork a child process then exec sqlplus from the child. This is a
snippet from an existing
Hi Thomas,
A couple of suggestions :
Firstly, with regard to LongReadLen, the simplest solution is to perform
an extra fetch *prior* to your existing one. For example, if your
existing fetch is something like this :
select col1, col2, ... clob_col
from some_table
where some_where_clause
You may also want to check out the 9i supplied package dbms_metadata.
It can generate DDL for any database object.
-Original Message-
From: Andy Hassall [mailto:[EMAIL PROTECTED]
Sent: Friday, 30 January 2004 11:26 AM
To: Rice, Wayne R (Sybase); [EMAIL PROTECTED]
Subject: Re: How-To
This is not a DBI restriction, but an Oracle one. For example, from
SQL*Plus ...
SQL var p number
SQL select * from table(test_pkg.f_test(:p));
select * from table(test_pkg.f_test(:p))
*
ERROR at line 1:
ORA-22905: cannot access rows from a non-nested table item
Not sure why this
Dennis,
You simply need to ensure you set the database handle attribute -
LongReadLen to a value big enough to read the LOB in one go. What I
usually do is to issue an initial SELECT to obtain the max length of a
LOB I'm about to fetch, use that value to set LongReadLen, and then
execute the
Try this ...
if (defined $col) {
:
} else {
:
}
Or ...
unless (defined $col) {
:
}
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, 4 March 2004 3:44 PM
To: [EMAIL PROTECTED]
Subject: NULL columns and undef
What if some code in a trigger on the table did a NEXTVAL on the sequence?
Probably not applicable in this case, but I think it is possible without
being in a threaded environment.
I happen to agree with Ron for all his reasons plus one other. If you put
the code in a trigger, it guarantees the
PL/SQL Tables (arrays) are not supported by DBD::Oracle. In this particular
situation, one solution may be to do something like this :
CREATE OR REPLACE PACKAGE mystorage IS
TYPE my_tagnames IS TABLE OF varchar2(200) INDEX BY BINARY_INTEGER;
prmTagNames my_tagnames ;
prmTagValues
1 - 100 of 112 matches
Mail list logo
