- Original Message -
From: Wilson, Doug [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 05, 2001 07:34
Subject: RE: Marketing DBI
PRO:
1) We have alot of SQL*Plus scripts here, DBI is not even officially
installed. The scripts have to write to a log
That looks like a problem with ActiveState's archive. You'll have a better
chance of a useful answer if you ask on one of their mail lists for help.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a
Ilya is the one of the members of the dbi-users list. If you looked at the
message, you'd see that Tim forwarded the second request to the list to be
handled, just like he probably did the first.
Tim is very busy. If you want to be shunned, continue talking that way to
the people who are
If you are using ActiveState's Perl build (and you probably should be), just
use PPM to install DBI and DBD-Oracle or DBD-Oracle8. You will also need at
least SQL*Net on any of your Win32 hosts.
The instructions for using PPM are part of the documentation that comes with
ActiveState Perl.
--
Mac
The warning indicates that you have a statement handle that you have not
fetched from until it indicated there are no more rows.
You might try assigning undef to the new statement's handle when you are
finished with it.
--
Mac :})
** I normally forward private database questions to the DBI mail
It is most likely that the process your webserver is running in doesn't have
the necessary environment variables (at least ORACLE_HOME and
LD_LIBRARY_PATH) set. Ask you webmaster to set them.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a
DBI 1.16 has been released, so it should be used in preference to 1.15 or
1.14.
The errors Denis is seeing look more like a problem with LD_LIBRARY_PATH
than the DBI 1.14 to DBD::Oracle 1.06 problem.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a
What Tommy and Chris said. :})
Let the Perl interpreter do some of the syntax checking for you. You should
have -w in the #! line and 'use strict;' (without the quotes) near the top
of your file.
It's easier to use $DBI::errstr to get the error message. It always
contains the error string
Unless you are trying to get the very very latest version of a module, you
should get it from CPAN. I think the preferred starting point these days is
http://cpan.perl.org/ .
Why do you think you need a non-current version of DBD::Oracle?
--
Mac :})
** I normally forward private database
That answer is fine if you are planning to do other things in the PL/SQL
block beyond the select.
# in a block: (note that '?' type placeholders also work)
# The variable $vbb_ver_nr won't be interpolated inside q{}.
# I replaced it with a placeholder.
my $sth = $dbh-prepare(q{
BEGIN
Suggestion: Don't do that. :}b
Read up on %SIG in 'perldoc perlvars'. If you trap the signal and exit from
the signal handler, an END{} block can clean up. It mostly depends on
whether the signal can be trapped.
Without more details it is hard to be more specific.
--
Mac :})
** I normally
I usually code that as:
foreach ( @ar1, $var1, $var2, @ar2 ) { $_ = '' if ! defined $_; }
TMTOWTDI!
The undef values generally don't cause trouble unless you are interpolating
them into a string. Unfortunately, I frequently do that with most
variables, so I generally convert undef to '' for
It isn't safe to actually _use_ a database handle created in the parent in
the child. To avoid having children attempt to disconnect for you during
their destruction, set $dbh-{InactiveDestroy} in each child.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
You are overriding the lexical variable $titel in the while() statement.
Leave out the 'my $titel =' and the variable you already bound with the
bind_columns() will have the value.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll
You are not giving us much to go on. Please send us what the README
recommends when asking for help.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
-
The failure you are getting in plsql.t is a known problem between DBI 1.15
and DBD::Oracle's ORA_RSET return handling. If you don't need to return
cursors from PL/SQL, ignore the error and install, otherwise drop back to
DBI 1.14.
--
Mac :})
** I normally forward private database questions to
The failure you are getting in plsql.t is a known problem between DBI 1.15
and DBD::Oracle's ORA_RSET return handling. If you don't need to return
cursors from PL/SQL, ignore the error and install, otherwise drop back to
DBI 1.14.
--
Mac :})
** I normally forward private database questions to
This question belongs in dbi-users, not dbi-dev. Unless you are offering to
supply a patch to DBI or a DBD.
Comments interspersed.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and
Tim would probably be glad to add a How to get started with DBI document
to the DBI distribution if you send him one. The DBD::Oracle distribution
has a small directory of working example scripts.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit
Documentation patches are always welcome.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From: Hamilton, Andrew Mr RAYTHEON 5
The test failure is a result of a problem in DBI 1.15. If you downgrade to
DBI 1.14, DBD::Oracle 1.06 should complete the tests correctly.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring
You need to have at least SQL*Net installed in your client machine. The
ORACLE_HOME it resides in on the local machine is what should be in the
environment variable.
The name you use to connect to the database should be in your local
TNSNames.ora file. Your local DBA can help you set it up.
--
If your DBD supports placeholders, you should use them.
If it does not, you should use $dbh-quote() on strings to make sure they
are properly quoted and escaped.
Just putting quotes (' or ) in the statement doesn't properly take care of
data containing those quotes.
--
Mac :})
** I normally
You really need error checking. I suggest you add { RaiseError = 1 } after
the password in the connect() call.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an
If you have the Oracle client softwar installed, you should be able to add
an entry to TNSNames.ora using EasyConfig (or some similar name) that is
part of the Oracle folder under your Start Menu. Your local DBA should be
able to give you the necessary details.
--
Mac :})
** I normally forward
How many arguments does proc_name() take?
You need to supply a separate placeholder for each argument to the
procedure. If this section in the fine manual (perldoc DBI) is not clear,
please suggest alternate wording.
=
Also, placeholders can only represent single scalar values.
For example,
All the pre-built modules that ActiveState distributes using PPM were built
to run in Win32. The only difference between DBD-Oracle and DBD-Oracle8 is
the OCI version they were compiled against.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a
Its in the fine manual (perldoc DBI). If this is unclear, please submit a
suggestion for improvement.
BNull Values
Undefined values, or Cundef, can be used to indicate null values.
However, care must be taken in the particular case of trying to use
null values to qualify a CSELECT statement.
Once you have associated a type with a placeholder in a statement, DBI
remembers the type, so you could do something like this (untested):
use DBI ( :sql_types );
# _Always_ check for errors
$dbh - {RaiseError} = 1;
my $sth = $dbh - prepare( ... );
# This value gets replaced in the
You might be surprised, check http://www.perl.org/ to see if there are any
local PerlMongers.
If you are using RPM to install Perl, you need to get your modules from the
same source. If you can't get DBI or the necessary DBDs from there, build
Perl yourself and then add any necessary modules.
I would
$dbh - {RaiseError} = 1;
my $sth = prepare();
$sth - execute( ... );
$sth - bind_columns( \( ... ) );
while ( $sth - fetch ) {
}
They are all described in the fine manual (perldoc DBI).
--
Mac :})
** I normally forward private database questions to the DBI mail lists.
fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From: Rozengurtel, Daniel [EMAIL PROTECTED]
To: 'Michael A. Chase' [EMAIL PROTECTED]
Sent: Thursday, May 10, 2001 12:07
Subject: RE: SELECT
Hi, Actually i got it the other way :)
my $statement =select
This is a known problem with registry access during global cleanup. Assign
undef to your handle variables ($dbh = $sth = undef;) after you
disconnect().
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a
I could go along with a 'finish() called on a completed query' complaint,
but I've left code behind at client sites that uses $sth-finish() and is
unlikely to be updated or reviewed anytime in the foreseeable future.
--
Mac :})
** I normally forward private database questions to the DBI mail
'?' placeholders get converted into ':1' style placeholders inside
DBD::Oracle, so there should be no reason that they wouldn't work. The
examples in DBD-Oracle-1.06/Oracle.ex/ use named placeholders like ':value'
because they are easier to keep straight, but they are not required.
The
I don't use ODBC, so I can only make some general observations (###).
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From:
That's one of the banes of email lists. The reply-to address for any mail
you send here is your email address, so if it bounces from any of the
billions of addresses in the list, you get the bounce message. The
turnaround at the list server is quick enough that you can just wait a half
hour to
gcc thinks the directory it is trying to write its temporary files is full.
Could it be trying to use a non-existent or excessively large directory?
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a
To get much further, we will need to see enough of your code to make some
sense of it.
Do you have $dbh-{RaiseError} set? If not, you may have a failure
somewhere else with no indication of what occurred.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give
Your best bet would be to get the sources and build Perl and your desired
modules from scratch using gcc. That way all the settings will be
consistent.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a
How about applying the corrections and suggestions provided earlier on this
list?
The DBI.errstr all by itself should get you a warning if you add 'use
strict;' to the script and '-w' to the '#!' line. There are almost
certainly other problems that those two additions would expose too.
--
Mac
It's a known problem between DBI 1.15 and DBD::Oracle's return cursor
handling. Drop back to DBI 1.14 and re-build DBD::Oracle.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll
Try building and installing DBI 1.14 then rebuilding DBD::Oracle. There is
a known problem with cursor variables that will be fixed in DBI 1.16.
This list is the appropriate place for questions. Please don't bother Tim,
it only delays his work on the next version.
--
Mac :})
** I normally
DBI is just a way to call SQL. If you will read it, a book on basic SQL
would be a good investment.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
-
What's needed is a documentation patch. Attribute ora_ph_type already
handles this situation. If I recall, it can be either an attribute in
bind_param() or a database handle attribute.
I think what Michael needs would be handled by either of these, but I
haven't tried them myself:
Please run 'perldoc DBI' and read the fine manual. There are several
examples in there. Programming the Perl DBI from Oreilly would be another
good investment, if you read it.
One hint: $! does _not_ contain the DBI error message, use $DBI::errstr
instead.
--
Mac :})
** I normally forward
questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From: Sterin, Ilya [EMAIL PROTECTED]
To: 'Michael A. Chase ' [EMAIL PROTECTED]; ''Fox, Michael ' '
[EMAIL PROTECTED]; [EMAIL
That wee fact does make a bit of a difference...
Unless you have more than a few hundred rows in the error table, you are
probably doing the best you can.
If the tables are fairly large, it might be worth using an ORDER BY clause
in both queries so the rows are fetched in the same order. You
If the script works from the shell, but not when running from the webserver,
the problem is with the account the webserver is running under. Either the
webserver process doesn't have some of the environment variables set that
your shell account does or some of the required files are not
The most common cause for this is that the webserver process doesn't have
either or both of ORACLE_HOME and LD_LIBRARY_PATH defined or one of them
does not have the correct directories in them. You can usually set
ORACLE_HOME inside your script, but it is usually better to set both in the
Get either Pro*C or OCI installed in the Linux machine. One or the other
should be in the CD or archive you installed the Oracle client software
from.
Please send further questions to dbi-users, Tim is very busy. You will note
that your question was delayed a day for him to forward it to the
You would be far better off getting it added to the webserver configuration.
That way when a new version of Oracle is installed ORACLE_HOME only has to
change in one place.
To see how to change an environment variable in a script, run 'perldeoc
perlvar' and search for %ENV.
--
Mac :})
** I
Those snippets all by themselves look innocuous enough, but I don't see any
error checking. The prepare()s might be failing. If you don't have
$dbh-{RaiseErrors} set, add 'or die Prepare xxx failed, $DBI::errstr\n'
to each prepare() call.
If you do have error checking on, I'd like to see the
Unless you do something to force it, Oracle doesn't actually describe the
statement (fetch table and column information from the database) until
execute() time. Then it also normally fetches the first buffer full of rows
which can be very expensive for large tables.
A SELECT * FROM table may be
Oracle's fine manuals include examples of similar triggers. Reading them
would be a good idea.
Once you've written the CREATE TRIGGER statement, you can use $dbh-do() to
load it, but it would probably be easier to just keep it in its own .sql
file and use SQL*Plus to create it.
--
Mac :})
** I
You can use a single version for remote database access since DBI, like any
OCI application is compiled against the Oracle OCI libraries. For remote
access, the OCI libraries use SQL*Net which can adapt across various
database versions. Different versions of SQL*Net may require different
This does _NOT_ belong in dbi-dev, so I'm replacing that with dbi-users.
Comments below.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original
Where did you find those docs? They need to be corrected.
All the examples that appear in the fine manual (perldoc DBD::ODBC) show it
in uppercase and the DBI manual states that the case of the driver name does
matter. The 'dbi' in the DSN is supposed to be lowercase, but uppercase has
been
A.
With sufficient flattery (see Notebooks of Lazarus Long) Tim or some one
else would probably be glad to add them.
You might also look at Oracle-OCI for more direct access to OCI from Perl.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a
You'd probably be better off using the prepare() and execute() _methods_ as
described in the fine manuals. Run 'perldoc DBI' to see some examples.
Placeholders would also be a good idea to limit the opportunity for
ill-intentioned users to slip and extra SQL statement in on you.
--
Mac :})
** I
This question belongs in dbi-users, not dbi-dev.
Run 'perldoc DBI' and 'perldoc DBD::Oracle' and read the fine manuals.
There are working example scripts in Oracle.ex/ in DBD-Oracle-1.06.tar.gz
which you can download from CPAN. Oracle.ex/commit would be especially
appropriate in your case.
If
This question belongs in dbi-users, not dbi-dev.
Run 'perldoc DBI' and 'perldoc DBD::Oracle' and read the fine manuals.
There are working example scripts in Oracle.ex/ in DBD-Oracle-1.06.tar.gz
which you can download from CPAN. Oracle.ex/commit would be especially
appropriate in your case.
If
If your problem is that plsql.t test 55 failed, this is a known issue with
DBI 1.15 and DBD::Oracle 1.06. If no other failures were reported, you may
install DBD::Oracle.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish
Interspersed.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From: "Reuss, Bob" [EMAIL PROTECTED]
To: "'M
That's libwin32 version 0.16. It's available in CPAN, but if you are using
ActiveState Perl, you should install it using PPM.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll
I'm not sure I'd call them friends.
In any case, you should have received instructions that included how to
unsubscribe.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat
Tim has said that there is a problem with test 55 in plsql.t. Since the
following tests depend on it, they should also be ignored.
If you had no other failed tests, you may install DBD::Oracle.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a
Buy and read "Programming the Perl DBI".
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
- Original Message -
From: "Sumic Leonard" [EMAIL
It means exactly what it says, you don't have OCI installed. If you are
going to build DBD::Oracle, you need to have Pro*C or OCI installed.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a
It was not just you.
If you look at the headers on the bounced messages, the actual subscriber
was forwarding to webdeveloper2000 which apparently was over its quota. I
don't think I've received a bounce from the last couple messages I've sent,
so the offending account has probably been removed
If he has MSVC, he has nmake. If he doesn't, he also doesn't have the
compiler or libraries he needs to build DBD::Oracle using nmake.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and
It appears that InterWoven used some version of Microsoft Visual C++ (MSVC)
to build perl.exe. In order to build DBI and DBD::Oracle, you need the
same version of Microsoft Visual C++ (MSVC). If you don't install Microsoft
Visual C++ (MSVC), you have neither a C compiler nor the compatible C
ActiveState has added distributions for Linux and Solaris 2.6 since at least
Build 611 though I don't think I have seen anyone here that is using them
yet.
For most UNIXs, building Perl and supporting modules is very straight
forward. You'd probably be best advised to use ActiveState's Perl for
If you can, install it in the same location as InterWoven used. See the
libpth in 'perl -V' output to tell you where. If you can't, perhaps you can
edit Config.pm to reflect the correct paths to the MSVC components.
--
Mac :})
** I normally forward private database questions to the DBI mail
If you really have ActiveState Perl, PPM is the correct way to install
modules. There are some special things you have to do if you are behind a
firewall. Other issues are covered in the PM documentatino that is part of
the ActivePerl Online Documentation.
An exact log of your attempt to load
My system with ActivePerl has never had DBD::Oracle8 loaded, just
DBD::Oracle.
Is the DBD::Oracle documentation in the Online Documentation in your
DBD::Oracle8 only machine?
If it is a problem with the PPM module, you should report it to ActiveState.
Their mail lists are described at
'Just move the modules' is not the instruction for installing modules in
ActiveState Perl. Look up PPM in the fine Online Documentation that came
with ActiveState Perl and follow the instructions.
The usual 'perl Makefile.pl ...' process doesn't normally work with
ActiveState Perl, but
If it's not ActiveState Perl, you need to build the modules with the same C
compiler and libraries as were used to create Perl. You can find out most
of that information by running 'perl -V'.
If they didn't use MSVC, you will probably also need to use dmake in place
of nmake which is available
Setting LD_LIBRARY_PATH inside a Perl script works in some platforms and
doesn't in others. I'm not sure which are which, so I try real hard to have
all the environment variables set before the script starts.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
There are a couple examples in the output from 'perldoc DBD::Oracle'. You
can also see a working script that calls a procedure if you download
DBD-Oracle-1.06.tar.gz from CPAN and look in Oracle.ex/.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a
You are not giving us much to go on. A short sample of the code that is
calling DBI would help us with our guesses.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for
Not including quotes or placeholders in the second argument to LIKE is very
dangerous. See below.
You are also assuming that all fields will have an associated full_entry
that is not NULL and is suitable as a LIKE matching expression.
--
Mac :})
** I normally forward private database questions
I think it would mostly be a matter of what you are comfortable with.
Embedding perl in a C++ application has a well defined interface, but
probably involves more overhead than a standalone Perl module that provides
the database service. On the gripping hand, the server process may become a
Maybe.
You definitely need at least Pro*C/OCI and SQL*Net to _BUILD_ DBD::Oracle.
You also need to build DBI first.
If the client is Win32, you should be using ActiveState's Perl builds. In
that case, ActiveState has already built DBI and DBD::Oracle for you and you
can install them using PPM.
You can usually connect to most any Oracle 7 or Oracle 8 instance as long as
you go through SQL*Net to get there.
What might cause trouble is if DBD::Oracle was compiled against one version
of Oracle but running in a host (or ORACLE_HOME) with a different version of
the Oracle client software.
Tim has indicated that there may be a problem with test 55 in t/plsql.t. If
that's your only test failure, there should be no problem installing
DBD::Oracle.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
The exact method Oracle uses to align the types of a DATE column and a
string placeholder can vary and may have performance impacts. Explicitly
converting date strings to Oracle DATEs as shown by Ronald avoids those
risks.
--
Mac :})
** I normally forward private database questions to the DBI
and he'll eat fish for an age.
- Original Message -
From: "Tarou, Kirk" [EMAIL PROTECTED]
To: "'Michael A. Chase'" [EMAIL PROTECTED]
Sent: Tuesday, April 03, 2001 10:55 AM
Subject: RE: DBD::Oracle 'make test' fails (t/plsql 55-63)
Once it fails on test 55, it stops testi
You _might_ get away with it with some RDBMSs, but I wouldn't count on it.
I know for certain it doesn't work with Oracle.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat
One thing you can do with the archive is read all the interesting README
files in there.
If you are using the ActiveState build of Perl, your ought to use PPM to
install DBI and DBD::???. If you aren't, follow the instructions in the
README file.
--
Mac :})
** I normally forward private
If "host=localhost;sid=TEST1" in place of "TEST1" works, you have an error
in tnsnames.ora.
How to fix it depends on your platform. Most Win32 Oracle installs have a
Easy*Net icon that starts a program that will build TNS entries for you. On
most other platforms, you will have to add the entry
If "host=localhost;sid=TEST1" in place of "TEST1" works, you have an error
in tnsnames.ora.
How to fix it depends on your platform. Most Win32 Oracle installs have a
Easy*Net icon that starts a program that will build TNS entries for you. On
most other platforms, you will have to add the entry
I got similar results combining DBI 1.15 with DBD::Oracle 1.06 under WinNT
4.0 SP4, Oracle 8.1.5.0.0, and Perl 5.6.0.
Please run this script and send the results to the list:
#!perl -w
use DBI;
use DBD::Oracle qw(ORA_RSET);
use strict;
$| = 1;
my $dbuser = $ENV{ORACLE_USERID} ||
If you expect to do this more than once, you should use placeholders. See
below.
I recommend you not use $a and $b outside the comparison block for sort(),
they cause the Perl compiler stage to act in special ways throughout the
code if they are found anywhere.
--
Mac :})
** I normally forward
Is cl.exe on the system path?
Where is it installed? (there have been reports of problems when it is
installed under directories with spaces in the directory names)
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a
Try setting ORACLE_HOME and ORACLE_SID, clearing TWO_TASK, and using
'dbi:Oracle:' for the connect string and see if that helps.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll
Most Perl modules have to be able to compile on a wide variety of C
compilers. As a result, 'unused variables' may occur; they are not normally
a problem.
Make sure your account has at least read and execute permission on all
directories leading up to DBI???.so. You also need to be able to
There are several example scripts in Oracle.ex/ in the archive
DBD-Oracle-1.06.tar.gz which you can download from CPAN
http://www.cpan.org/.
Run 'perldoc DBI' to read the fine manual which describes (among many other
things) how to establish a database connection.
--
Mac :})
** I normally
If you are using ActiveState's Perl binary distribution, use PPM.
Otherwise, build them like any other module. Once you download the archives
from CPAN, follow the instructions in the README files.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a
I'd probably do it the same way you are describing. A named pipe to
establish communications with the C++ daemon might be helpful. Wrapping the
C++ functions you need in an XS module might be another possibility.
--
Mac :})
** I normally forward private database questions to the DBI mail lists.
701 - 800 of 848 matches
Mail list logo
