On 13.07.2007 21:59, Craig Metzer wrote:
Alexander,Thanks for the tip. We have an enterprise license. We run it on Sun servers, but my script is on a Linux box.
That should be no problem, all you need is a set of Oracle client
libraries to compile and run DBD::Oracle on Linux. Ask your local Oracle
DBA or the one (s)he asks for help. ;-)
If installing Personal Oracle is easy, then I'll do it.
The last time I tried, Oracle was at Version 8, and it was painful
because I did not use Oracles prefered Linux distribution. But things
should have become better since then. In the worst case, confiscate an
old Windows box (any NT4/Win2K/WinXP workstation will do, no need for a
Windows "Server" license) and install the Windows version of Personal
Oracle there. It won't be fast, but it will work.
Or ask your DBA for 100 MB on one of the sun servers, an isolated table
space and a login dedicated to our development
But to interface to the remote Oracle db, I'll still need ODBC, right?
No.
ODBC is not remote access to a database, ODBC is a layer on top of
native drivers to present applications a unique interface. If you link a
C program against an ODBC library, it can communicate with any database
for which you can find an ODBC driver. Essentially, ODBC and ODBC
drivers are the same concept as DBI and DBD::xxx drivers and JDBC and
JDBC drivers. DBD::ODBC is a nice trick to gain access to a large set of
existing database drivers (all ODBC drivers you can find) from DBI. And
there is also a DBD::JDBC to get Perls fingers on every database for
which you can find a JDBC driver. But DBD::ODBC and DBD::JDBC share one
bad point: They stack layers and layers over a native driver, making
eveything slower then it could be. So they both are just an excuse for
unavailable native drivers.
Oracle usually uses TCP/IP Port 1521 for the entire SQL communication.
It can use other mechanisms for local connections, but 1521/tcp is the
most coommonly used way to speak with an Oracle DB. If you can establish
a TCP connection from your linux box to port 1521 on one of the Sun
servers (using a perl script with sockets, nmap, or simply telnet
sunserver.your.lan 1521), chances are very good that you can use a
native connection. If you get a "connection refused", your DBA may have
moved Oracle to another port. Find a box that has a working connection
and search for a file named $ORACLE_HOME/network/admin/tnsnames.ora or
$ORACLE_HOME/net80/admin/tnsnames.ora, it usually contains all the
information you need. Or look how the ODBC driver is configured to
connect to the sun server. Some other commonly used ports are 1526 and
1525 (ancient).
The native Oracle driver (part of the client library set you get from
some Oracle CDROM or download) uses the tnsnames.ora file to find the
right way to connect to the Oracle database, no matter if it runs on the
same machine or a fat server 20.000 km away. It does a good job hiding
all the complexity of communication with the server from you.
The script I'm writing is for a very simple db.
Small data ammounts are no excuse for not using Oracle. ;-)
I'm writing a utility that uses NSAPping to get availability and latency for our ATM network. Two small tables. I could use a flat file for output, but I'd like to automate Crystal Reports to build the monthly availability reports, and Crystal uses a db interface, so at db is the best solution ... besides, Oracle will do all the data maintenance, rollups, etc.
Right.
Alexander
--
Alexander Foken
mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
