OK. Thanks for the advice.
Cheers, Craig ---------------------------------------- > Date: Fri, 13 Jul 2007 22:56:24 +0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [email protected] > Subject: Re: Trouble Installing DBD::ODBC with postgresql > > 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/ > _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlmailtextlink
