Wow, that's a tough one. It really depends on what you want/need from
your database. What's your recoverability liability? How scalable do
you need your app? Platform/OS requirements?
Being from primarily an Oracle background (as far as DBs go), I'd say
overall Oracle. Free? Yes! There's
Hey all,
We're (finally!) migrating our Windows XP Oracle clients from 8.0.5 to
9.2.0.6. While testing some AS Perl v5.6 that uses DBD::Oracle, we've
found that it doesn't work with the 9i client. It keeps looking for the
8.0.5 or previous OCI DLLs. Using PPM, we see that DBD::Oracle is
v1.12,
...on making Oracle Open Source Dev of the year:
http://www.oracle.com/technology/oramag/oracle/04-nov/o64awards.html#BUNCE
Rich
Perhaps this'll help:
http://perl.apache.org/docs/1.0/guide/performance.html#Persistent_DB_Connections
There's a link on that site to Tim Bunce's Advanced DBI talk, but it returns a 500.
Tim???
Rich
Rich JesseSystem/Database Administrator
[EMAIL PROTECTED]
error either on the connect or maybe the
statement handle?
Rich
Rich JesseSystem/Database Administrator
[EMAIL PROTECTED] QuadTech, Sussex, WI USA
-Original Message-
From: Jesse, Rich [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 3:51 PM
To: Paul
Howdy,
I have a question from one of our developers that's been bugging me and I
can't find an answer. Given this v1.37 DBI code fragement:
while ( my ($projectno,$description,$dateclosed) = $sth-fetchrow_array )
{
print $projectno;
print $description;
print
-Original Message-
From: Michael Ragsdale [mailto:[EMAIL PROTECTED]
Sent: Monday, April 26, 2004 10:29 AM
To: Jesse, Rich
Subject: Re: Correct way to deal with returned NULLs?
You can place the following near the beginning of your script
to eliminate
those messages:
$SIG
:43 PM
To: Jesse, Rich
Cc: 'Michael Ragsdale'; '[EMAIL PROTECTED]'
Subject: Re: [DBI] RE: Correct way to deal with returned NULLs?
On Mon, 26 Apr 2004, Jesse, Rich wrote:
Thanks all for your responses. We went with Michael's
answer for this
project, although I'd probably advocate
It depends. If you want to use DBD::Oracle, then yes, you must install the
Oracle Database Software. You can choose to not install most of it, but
unfortunately Oracle doesn't make this very easy for developers outside of
Windohs.
Or, if you want a JDBC solution, you can download the 1.1MB
Hey Mike,
The OCI-21500 is definitely an Oracle problem. It's like the dreaded
ORA-600 error in that it should never happen. The main difference is that
OCI-21500 is a client problem.
Are you running an unpatched client (9.0.1.0.0)? If so, you'll want the
183MB 9.0.1.4.0 Linux patch from
Perhaps, but if you're using Oracle, you could store the password in the DB
as obfuscated, which is how Oracle refers to encryption. Tbe table
containing the password would be stored in a different schema than the one
to which you'd normally attach to. In order to get the password, you would
To see if the problem's in the Oracle side or the DBI side, does the SQL
statement run directly from SQL*Plus on the client? Have you tried using
the WE8ISO8859P1 NLS_LANG setting? Don't use the EBCDIC one on HP -- it
won't work.
A few other questions/points. Why are you using TO_CHAR? Or,
Do you have icky LONG datatypes that you are fetching? That could be one
cause.
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA
-Original Message-
From: Birchall, Austen [mailto:[EMAIL
Curious. Scott, what is your NLS_LANG and what is the character set
(SELECT * FROM V$NLS_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET')?
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA
-Original
If you're still running HPUX 10.x, I'm guessing that it's also an older
machine? It's probably not a memory issue, since SQL*Plus won't store the
38K rows in memory. There's some memory use, but it's more for buffering.
On your HP box, fire up top in another window while re-running that query.
Hey Tim,
Sorry I didn't get back to you sooner -- seems like MS Outlook (or
Lookout!) decided not to give me your reply. sigh
I've tried the level 9 trace -- I'm not exactly sure what it is I'm looking
for, but this seems to be an important area:
- connect= DBI::db=HASH(0x16ce78) at
Hi,
A Solaris system that I have little control over is running Perl 5.005_03,
and a DBI_TRACE level 2 shows DBI v1.13 and DBD::Oracle v1.03. The Oracle
client on the Solaris server is 8.0.5.0.0. The Oracle DB we're connecting
to is 8.1.7.4.0 on HP/UX.
After changing the 8.1.7 DB's
17 matches
Mail list logo
