Trouble Installing DBD::ODBC with postgresql

--_3b18e9ec-ca26-42b3-abef-25f107ff2fd7_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I'm having trouble installing DBD::ODBC 1.13 on a system with postgresql. =
It appears it's because it can't find the sql.h, sqlext.h, etc. headers. I=
installed the developer and library packages that were supposed to contain=
these headers. Could someone please tell me what I'm doing wrong or where=
to find the headers?
=20
TIA,
Craig
=20
~~~ install info ~~~~~~
=20
[mrtg@prod-netflow DBD-ODBC-1.13]$ perl Makefile.PLUseless use of private v=
ariable in void context at Makefile.PL line 431.
Configuring DBD::ODBC ...
>>> Remember to actually *READ* the README file! And re-read it =
if you have any problems.
Multiple copies of Driver.xst found in: /usr/lib64/perl5/site_perl/5.8.5/x8=
6_64-linux-thread-multi/auto/DBI/ /usr/lib64/perl5/vendor_perl/5.8.5/x86_64=
-linux-thread-multi/auto/DBI/ at Makefile.PL line 61Using DBI 1.58 (for per=
l 5.008005 on x86_64-linux-thread-multi) installed in /usr/lib64/perl5/site=
_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI/Using ODBC in /usr
Umm, this looks like a unixodbc type of driver manager.We expect to find th=
e sql.h, sqlext.h and (which weresupplied with unixODBC) in $ODBCHOME/inclu=
de directory alongsidethe /usr/lib/libodbc.so library. in $ODBCHOME/lib
Injecting selected odbc driver into cc commandInjecting selected odbc drive=
r into cc commandMultiple copies of Driver.xst found in: /usr/lib64/perl5/s=
ite_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI/ /usr/lib64/perl5/vendor_=
perl/5.8.5/x86_64-linux-thread-multi/auto/DBI/ at Makefile.PL line 462Using=
DBI 1.58 (for perl 5.008005 on x86_64-linux-thread-multi) installed in /us=
r/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto /DBI/Writing Ma=
kefile for DBD::ODBC
The DBD::ODBC tests will use these values for the database connection: D=
BI_DSN=3Ddbi:ODBC:pgsql e.g. dbi:ODBC:demo DBI_USER=3Dpostg=
res DBI_PASS=3Dpostgres
[mrtg@prod-netflow DBD-ODBC-1.13]$ rpm -qa | grep postgresqlpostgresql-7.4.=
13-2.RHEL4.1postgresql-devel-8.1.3-1.el4s1.2postgresql-libs- 7.4.13-2.RHEL4.=
1postgresql-pl-7.4.13-2.RHEL4.1postgresql-libs-8.1.3-1.el4s1 .2postgresql-od=
bc-7.3-8.RHEL4.1postgresql-server-7.4.13-2.RHEL4.1postgresql -test-7.4.13-2.=
RHEL4.1postgresql-contrib-7.4.13-2.RHEL4.1postgresql-python- 7.4.13-2.RHEL4.=
1postgresql-docs-7.4.13-2.RHEL4.1postgresql-contrib-7.4.13-2 .RHEL4.1postgre=
sql-jdbc-7.4.13-2.RHEL4.1postgresql-tcl-7.4.13-2.RHEL4.1post gresql-perl-7.1=
..3-7.rhel2.1AS[mrtg@prod-netflow DBD-ODBC-1.13]$ find /usr -name sql\*.h/us=
r/include/sql3types.h/usr/include/sqlca.h/usr/include/pgsql/ informix/esql/s=
qltypes.h/usr/include/pgsql/informix/esql/sqlda.h/usr/includ e/mysql/sql_sta=
te.h/usr/include/mysql/sql_common.h/usr/share/doc/qt-devel-3 .3.3/examples/d=
emo/sql/sqlex.ui.h/usr/local/include/sqltypes.h/usr/src/redh at/SOURCES/post=
gresql-7.4.13/src/bin/psql/sql_help.h/usr/src/redhat/SOURCES /postgresql-7.4=
..13/src/interfaces/ecpg/include/sql3types.h/usr/src/redhat/ SOURCES/postgres=
ql-7.4.13/src/interfaces/ecpg/include/sqlca.h/usr/src/redhat /SOURCES/postgr=
esql-7.4.13/src/interfaces/ecpg/include/sqltypes.h/usr/src/r edhat/SOURCES/p=
ostgresql-7.4.13/src/interfaces/ecpg/include/sqlda.h
=20
____________________________________________________________ _____
See what you=92re getting into=85before you go there.
http://newlivehotmail.com=

--_3b18e9ec-ca26-42b3-abef-25f107ff2fd7_--

Re: Trouble Installing DBD::ODBC with postgresql

Craig Metzer wrote:
> I'm having trouble installing DBD::ODBC 1.13 on a system with postgresql. It appears it's because it can't find the sql.h, sqlext.h, etc. headers. I installed the developer and library packages that were supposed to contain these headers. Could someone please tell me what I'm doing wrong or where to find the headers?
>
> TIA,
> Craig
>
> ~~~ install info ~~~~~~
>
> [mrtg@prod-netflow DBD-ODBC-1.13]$ perl Makefile.PLUseless use of private variable in void context at Makefile.PL line 431.
> Configuring DBD::ODBC ...
>>>> Remember to actually *READ* the README file! And re-read it if you have any problems.
> Multiple copies of Driver.xst found in: /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/a uto/DBI/ /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /auto/DBI/ at Makefile.PL line 61Using DBI 1.58 (for perl 5.008005 on x86_64-linux-thread-multi) installed in /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/a uto/DBI/Using ODBC in /usr
> Umm, this looks like a unixodbc type of driver manager.We expect to find the sql.h, sqlext.h and (which weresupplied with unixODBC) in $ODBCHOME/include directory alongsidethe /usr/lib/libodbc.so library. in $ODBCHOME/lib
> Injecting selected odbc driver into cc commandInjecting selected odbc driver into cc commandMultiple copies of Driver.xst found in: /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/a uto/DBI/ /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /auto/DBI/ at Makefile.PL line 462Using DBI 1.58 (for perl 5.008005 on x86_64-linux-thread-multi) installed in /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/a uto/DBI/Writing Makefile for DBD::ODBC
> The DBD::ODBC tests will use these values for the database connection: DBI_DSN=dbi:ODBC:pgsql e.g. dbi:ODBC:demo DBI_USER=postgres DBI_PASS=postgres
> [mrtg@prod-netflow DBD-ODBC-1.13]$ rpm -qa | grep postgresqlpostgresql-7.4.13-2.RHEL4.1postgresql-devel-8.1.3- 1.el4s1.2postgresql-libs-7.4.13-2.RHEL4.1postgresql-pl-7.4.1 3-2.RHEL4.1postgresql-libs-8.1.3-1.el4s1.2postgresql-odbc-7. 3-8.RHEL4.1postgresql-server-7.4.13-2.RHEL4.1postgresql-test -7.4.13-2.RHEL4.1postgresql-contrib-7.4.13-2.RHEL4.1postgres ql-python-7.4.13-2.RHEL4.1postgresql-docs-7.4.13-2.RHEL4.1po stgresql-contrib-7.4.13-2.RHEL4.1postgresql-jdbc-7.4.13-2.RH EL4.1postgresql-tcl-7.4.13-2.RHEL4.1postgresql-perl-7.1.3-7. rhel2.1AS[mrtg@prod-netflow DBD-ODBC-1.13]$ find /usr -name sql\*.h/usr/include/sql3types.h/usr/include/sqlca.h/usr/incl ude/pgsql/informix/esql/sqltypes.h/usr/include/pgsql/informi x/esql/sqlda.h/usr/include/mysql/sql_state.h/usr/include/mys ql/sql_common.h/usr/share/doc/qt-devel-3.3.3/examples/demo/s ql/sqlex.ui.h/usr/local/include/sqltypes.h/usr/src/redhat/SO URCES/postgresql-7.4.13/src/bin/psql/sql_help.h/usr/src/redh at/SOURCES/postgresql-7.4.13/src/inter
faces/ecpg/include/sql3types.h/usr/src/redhat/SOURCES/postgr esql-7.4.13/src/interfaces/ecpg/include/sqlca.h/usr/src/redh at/SOURCES/postgresql-7.4.13/src/interfaces/ecpg/include/sql types.h/usr/src/redhat/SOURCES/postgresql-7.4.13/src/interfa ces/ecpg/include/sqlda.h
>
> ____________________________________________________________ _____
> See what you’re getting into…before you go there.
> http://newlivehotmail.com

You need the unixODBC development RPM (unixodbc-dev) which contains
sql.h, sqltypes.h, sqlext.h and sqlucode.h.

Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: Trouble Installing DBD::ODBC with postgresql

Is there a special reason why you do not use DBD::Pg? It should be
faster because it has less overhead and it supports Unicode better than
DBD::ODBC, should you need it. DBD::ODBC has seen no update since about
three years, while the current DBD::Pg is just one year old.

Alexander

On 13.07.2007 00:11, Craig Metzer wrote:
> I'm having trouble installing DBD::ODBC 1.13 on a system with postgresql. It appears it's because it can't find the sql.h, sqlext.h, etc. headers. I installed the developer and library packages that were supposed to contain these headers. Could someone please tell me what I'm doing wrong or where to find the headers?
>
> TIA,
> Craig
>
>

--
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/

RE: Trouble Installing DBD::ODBC with postgresql

--_b6edcdad-f4ef-48d4-a0a1-5bba15b7269f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes Alexander,
=20
I'm only using the local pgsql server for the script development. After I =
get my Perl script worked out, I'm going to move the db to our enterprise O=
racle server. I'll need ODBC for that.
=20
Craig



> Date: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander@foken.de> To: ucan=
tspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re: Trouble Install=
ing DBD::ODBC with postgresql> > Is there a special reason why you do not u=
se DBD::Pg? It should be > faster because it has less overhead and it suppo=
rts Unicode better than > DBD::ODBC, should you need it. DBD::ODBC has seen=
no update since about > three years, while the current DBD::Pg is just one=
year old.> > Alexander> > On 13.07.2007 00:11, Craig Metzer wrote:> > I'm =
having trouble installing DBD::ODBC 1.13 on a system with postgresql. It ap=
pears it's because it can't find the sql.h, sqlext.h, etc. headers. I insta=
lled the developer and library packages that were supposed to contain these=
headers. Could someone please tell me what I'm doing wrong or where to fin=
d the headers?> > > > TIA,> > Craig> > > > > > -- > Alexander Foken> mailto=
:alexander@foken.de http://www.foken.de/alexander/>=20
____________________________________________________________ _____
Don't get caught with egg on your face. Play Chicktionary!  
http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink=

--_b6edcdad-f4ef-48d4-a0a1-5bba15b7269f_--

RE: Trouble Installing DBD::ODBC with postgresql

Why not use DBD::Oracle if you are moving to a Oracle server.

-----Original Message-----
From: Craig Metzer [mailto:ucantspamthis@hotmail.com]=20
Sent: Friday, July 13, 2007 1:12 PM
To: Alexander Foken
Cc: dbi-users@perl.org
Subject: RE: Trouble Installing DBD::ODBC with postgresql

Yes Alexander,
=20
I'm only using the local pgsql server for the script development. After
I get my Perl script worked out, I'm going to move the db to our
enterprise Oracle server. I'll need ODBC for that.
=20
Craig



> Date: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander@foken.de> To:=20
> ucantspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re:=20
> Trouble Installing DBD::ODBC with postgresql> > Is there a special=20
> reason why you do not use DBD::Pg? It should be > faster because it=20
> has less overhead and it supports Unicode better than > DBD::ODBC,=20
> should you need it. DBD::ODBC has seen no update since about > three=20
> years, while the current DBD::Pg is just one year old.> > Alexander> >

> On 13.07.2007 00:11, Craig Metzer wrote:> > I'm having trouble=20
> installing DBD::ODBC 1.13 on a system with postgresql. It appears it's

> because it can't find the sql.h, sqlext.h, etc. headers. I installed=20
> the developer and library packages that were supposed to contain these

> headers. Could someone please tell me what I'm doing wrong or where to

> find the headers?> > > > TIA,> > Craig> > > > > > -- > Alexander=20
> Foken> mailto:alexander@foken.de http://www.foken.de/alexander/>
____________________________________________________________ _____
Don't get caught with egg on your face. Play Chicktionary!
http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink

Re: Trouble Installing DBD::ODBC with postgresql

There is also a DBD::Oracle, also with less overhead than DBD::ODBC,=20
also with better Unicode support, also with the latest release being two =

years younger than DBD::ODBCs latest release.

Are you really sure you need ODBC?

Alexander

On 13.07.2007 21:11, Craig Metzer wrote:
> Yes Alexander,
> =20
> I'm only using the local pgsql server for the script development. Afte=
r I get my Perl script worked out, I'm going to move the db to our enterp=
rise Oracle server. I'll need ODBC for that.
> =20
> Craig
>
>
>
> =20
>> Date: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander@foken.de> To: u=
cantspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re: Trouble In=
stalling DBD::ODBC with postgresql> > Is there a special reason why you d=
o not use DBD::Pg? It should be > faster because it has less overhead and=
it supports Unicode better than > DBD::ODBC, should you need it. DBD::OD=
BC has seen no update since about > three years, while the current DBD::P=
g is just one year old.> > Alexander> > On 13.07.2007 00:11, Craig Metzer=
wrote:> > I'm having trouble installing DBD::ODBC 1.13 on a system with =
postgresql. It appears it's because it can't find the sql.h, sqlext.h, et=
c. headers. I installed the developer and library packages that were supp=
osed to contain these headers. Could someone please tell me what I'm doin=
g wrong or where to find the headers?> > > > TIA,> > Craig> > > > > > -- =
> Alexander Foken> mailto:alexander@foken.de http://www.foken.de/alexande=
r/>=20
>> =20
> ____________________________________________________________ _____
> Don't get caught with egg on your face. Play Chicktionary! =20
> http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink
> =20


--=20
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/

Re: Trouble Installing DBD::ODBC with postgresql

Oh, I almost forgot: If your company has a licensed Oracle server, you=20
can get "Personal Oracle" for free (as far as I know, perhaps you can=20
even get it for free without a licensed server), so you can develop and=20
run productive on the same DB engine. Don't get me wrong, PostgreSQL is=20
a cool DB, but developing for more than one DB can be really painful.

Alexander

On 13.07.2007 21:11, Craig Metzer wrote:
> Yes Alexander,
> =20
> I'm only using the local pgsql server for the script development. Afte=
r I get my Perl script worked out, I'm going to move the db to our enterp=
rise Oracle server. I'll need ODBC for that.
> =20
> Craig
>
>
>
> =20
>> Date: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander@foken.de> To: u=
cantspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re: Trouble In=
stalling DBD::ODBC with postgresql> > Is there a special reason why you d=
o not use DBD::Pg? It should be > faster because it has less overhead and=
it supports Unicode better than > DBD::ODBC, should you need it. DBD::OD=
BC has seen no update since about > three years, while the current DBD::P=
g is just one year old.> > Alexander> > On 13.07.2007 00:11, Craig Metzer=
wrote:> > I'm having trouble installing DBD::ODBC 1.13 on a system with =
postgresql. It appears it's because it can't find the sql.h, sqlext.h, et=
c. headers. I installed the developer and library packages that were supp=
osed to contain these headers. Could someone please tell me what I'm doin=
g wrong or where to find the headers?> > > > TIA,> > Craig> > > > > > -- =
> Alexander Foken> mailto:alexander@foken.de http://www.foken.de/alexande=
r/>=20
>> =20
> ____________________________________________________________ _____
> Don't get caught with egg on your face. Play Chicktionary! =20
> http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink
> =20


--=20
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/

RE: Trouble Installing DBD::ODBC with postgresql

--_3d9d636a-a61a-466c-b7f2-bb6b9af9a380_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can I do that if the db is on a remote Oracle server? How do I interface t=
o it? =20
Craig



> Subject: RE: Trouble Installing DBD::ODBC with postgresql> Date: Fri, 13 =
Jul 2007 13:15:19 -0600> From: imharisa@nuskin.com> To: dbi-users@perl.org>=
> Why not use DBD::Oracle if you are moving to a Oracle server.> > -----Or=
iginal Message-----> From: Craig Metzer [mailto:ucantspamthis@hotmail.com] =
> Sent: Friday, July 13, 2007 1:12 PM> To: Alexander Foken> Cc: dbi-users@p=
erl.org> Subject: RE: Trouble Installing DBD::ODBC with postgresql> > Yes A=
lexander,> > I'm only using the local pgsql server for the script developme=
nt. After> I get my Perl script worked out, I'm going to move the db to our=
> enterprise Oracle server. I'll need ODBC for that.> > Craig> > > > > Date=
: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander@foken.de> To: > > ucants=
pamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re: > > Trouble Insta=
lling DBD::ODBC with postgresql> > Is there a special > > reason why you do=
not use DBD::Pg? It should be > faster because it > > has less overhead an=
d it supports Unicode better than > DBD::ODBC, > > should you need it. DBD:=
:ODBC has seen no update since about > three > > years, while the current D=
BD::Pg is just one year old.> > Alexander> >> > > On 13.07.2007 00:11, Crai=
g Metzer wrote:> > I'm having trouble > > installing DBD::ODBC 1.13 on a sy=
stem with postgresql. It appears it's> > > because it can't find the sql.h,=
sqlext.h, etc. headers. I installed > > the developer and library packages=
that were supposed to contain these> > > headers. Could someone please tel=
l me what I'm doing wrong or where to> > > find the headers?> > > > TIA,> >=
Craig> > > > > > -- > Alexander > > Foken> mailto:alexander@foken.de http:=
//www.foken.de/alexander/>> _______________________________________________=
__________________> Don't get caught with egg on your face. Play Chicktiona=
ry!> http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink
____________________________________________________________ _____
Missed the show?=A0 Watch videos of the Live Earth Concert on MSN.
http://liveearth.msn.com=

--_3d9d636a-a61a-466c-b7f2-bb6b9af9a380_--

RE: Trouble Installing DBD::ODBC with postgresql

--_b84aa23e-f59c-4d9d-a4fe-b384f1795364_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Alexander,Thanks for the tip. We have an enterprise license. We run it on=
Sun servers, but my script is on a Linux box. If installing Personal Orac=
le is easy, then I'll do it. But to interface to the remote Oracle db, I'l=
l still need ODBC, right? The script I'm writing is for a very simple db. =
I'm writing a utility that uses NSAPping to get availability and latency fo=
r 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. Craig

> Date: Fri, 13 Jul 2007 21:29:50 +0200> From: alexander@foken.de> To: ucan=
tspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: Re: Trouble Install=
ing DBD::ODBC with postgresql> > Oh, I almost forgot: If your company has a=
licensed Oracle server, you > can get "Personal Oracle" for free (as far a=
s I know, perhaps you can > even get it for free without a licensed server)=
, so you can develop and > run productive on the same DB engine. Don't get =
me wrong, PostgreSQL is > a cool DB, but developing for more than one DB ca=
n be really painful.> > Alexander> > On 13.07.2007 21:11, Craig Metzer wrot=
e:> > Yes Alexander,> > > > I'm only using the local pgsql server for the s=
cript development. After I get my Perl script worked out, I'm going to move=
the db to our enterprise Oracle server. I'll need ODBC for that.> > > > Cr=
aig> >> >> >> > > >> Date: Fri, 13 Jul 2007 20:57:03 +0200> From: alexander=
@foken.de> To: ucantspamthis@hotmail.com> CC: dbi-users@perl.org> Subject: =
Re: Trouble Installing DBD::ODBC with postgresql> > Is there a special reas=
on why you do not use DBD::Pg? It should be > faster because it has less ov=
erhead and it supports Unicode better than > DBD::ODBC, should you need it.=
DBD::ODBC has seen no update since about > three years, while the current =
DBD::Pg is just one year old.> > Alexander> > On 13.07.2007 00:11, Craig Me=
tzer wrote:> > I'm having trouble installing DBD::ODBC 1.13 on a system wit=
h postgresql. It appears it's because it can't find the sql.h, sqlext.h, et=
c. headers. I installed the developer and library packages that were suppos=
ed to contain these headers. Could someone please tell me what I'm doing wr=
ong or where to find the headers?> > > > TIA,> > Craig> > > > > > -- > Alex=
ander Foken> mailto:alexander@foken.de http://www.foken.de/alexander/> > >>=
> > ____________________________________________________________ _____> > D=
on't get caught with egg on your face. Play Chicktionary! > > http://club.l=
ive.com/chicktionary.aspx?icid=3Dchick_wlmailtextlink> > > > > -- > Alexand=
er Foken> mailto:alexander@foken.de http://www.foken.de/alexander/> >=20
____________________________________________________________ _____
PC Magazine=92s 2007 editors=92 choice for best web mail=97award-winning Wi=
ndows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=3Den-us&ocid= 3DTXT_TAGHM_mig=
ration_HMWL_mini_pcmag_0707=

--_b84aa23e-f59c-4d9d-a4fe-b384f1795364_--

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:alexander@foken.de http://www.foken.de/alexander/

RE: Trouble Installing DBD::ODBC with postgresql

OK. Thanks for the advice.

Cheers,
Craig

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

____________________________________________________________ _____
Don't get caught with egg on your face. Play Chicktionary!  
http://club.live.com/chicktionary.aspx?icid=3Dchick_wlmailte xtlink=

Re: Trouble Installing DBD::ODBC with postgresql

Alexander Foken wrote:
> Is there a special reason why you do not use DBD::Pg? It should be
> faster because it has less overhead and it supports Unicode better
> than DBD::ODBC, should you need it. DBD::ODBC has seen no update since
> about three years, while the current DBD::Pg is just one year old.
>
> Alexander
>
Just so everyone on the list knows. I did a development release of
DBD::ODBC (1.14_1) a little over a week ago. You can find it on cpan. It
fixes all bugs I know about except one on rt.cpan I have not sufficient
info as yet to look at. If anyone knows of any other issues please
report them on rt.cpan and I will look in to them. Unless I hear from
anyone I'll release 1.14 properly late next week.

Martin
> On 13.07.2007 00:11, Craig Metzer wrote:
>> I'm having trouble installing DBD::ODBC 1.13 on a system with
>> postgresql. It appears it's because it can't find the sql.h,
>> sqlext.h, etc. headers. I installed the developer and library
>> packages that were supposed to contain these headers. Could someone
>> please tell me what I'm doing wrong or where to find the headers?
>>
>> TIA,
>> Craig
>>
>>

Re: Trouble Installing DBD::ODBC with postgresql

On Sat, July 14, 2007 2:40, Martin J. Evans said:
> Alexander Foken wrote:
>> Is there a special reason why you do not use DBD::Pg? It should be
>> faster because it has less overhead and it supports Unicode better
>> than DBD::ODBC, should you need it. DBD::ODBC has seen no update since
>> about three years, while the current DBD::Pg is just one year old.
>>
>> Alexander
>>
> Just so everyone on the list knows. I did a development release of
> DBD::ODBC (1.14_1) a little over a week ago. You can find it on cpan. It
> fixes all bugs I know about except one on rt.cpan I have not sufficient
> info as yet to look at. If anyone knows of any other issues please
> report them on rt.cpan and I will look in to them. Unless I hear from
> anyone I'll release 1.14 properly late next week.
>
> Martin
>> On 13.07.2007 00:11, Craig Metzer wrote:
>>> I'm having trouble installing DBD::ODBC 1.13 on a system with
>>> postgresql. It appears it's because it can't find the sql.h,
>>> sqlext.h, etc. headers. I installed the developer and library
>>> packages that were supposed to contain these headers. Could someone
>>> please tell me what I'm doing wrong or where to find the headers?
>>>
>>> TIA,
>>> Craig
>>>
Please excuse my ignorance, but is DBD::ODBC still limited to one running
query through each Database Handle at a time? That is
$sth=$dbh->prepare(...); $sth->execute;
$sth1=$dbh->prepare(...);
$sth1 will invalidate $sth's result set. Stubbed my toe on this when I
was trying to apply DBD::mysql to DBD::ODBC (target MS-SQL server). Of
course that was a number of years ago.

Thanks.

Bill

DBD::ODBC multiple active statements (was Trouble Installing DBD::ODBCwith postgresql)

Wm Mussatto wrote:
> On Sat, July 14, 2007 2:40, Martin J. Evans said:
>> Alexander Foken wrote:
>>> Is there a special reason why you do not use DBD::Pg? It should be
>>> faster because it has less overhead and it supports Unicode better
>>> than DBD::ODBC, should you need it. DBD::ODBC has seen no update since
>>> about three years, while the current DBD::Pg is just one year old.
>>>
>>> Alexander
>>>
>> Just so everyone on the list knows. I did a development release of
>> DBD::ODBC (1.14_1) a little over a week ago. You can find it on cpan. It
>> fixes all bugs I know about except one on rt.cpan I have not sufficient
>> info as yet to look at. If anyone knows of any other issues please
>> report them on rt.cpan and I will look in to them. Unless I hear from
>> anyone I'll release 1.14 properly late next week.
>>
>> Martin
>>> On 13.07.2007 00:11, Craig Metzer wrote:
>>>> I'm having trouble installing DBD::ODBC 1.13 on a system with
>>>> postgresql. It appears it's because it can't find the sql.h,
>>>> sqlext.h, etc. headers. I installed the developer and library
>>>> packages that were supposed to contain these headers. Could someone
>>>> please tell me what I'm doing wrong or where to find the headers?
>>>>
>>>> TIA,
>>>> Craig
>>>>
> Please excuse my ignorance, but is DBD::ODBC still limited to one running
> query through each Database Handle at a time? That is
> $sth=$dbh->prepare(...); $sth->execute;
> $sth1=$dbh->prepare(...);
> $sth1 will invalidate $sth's result set. Stubbed my toe on this when I
> was trying to apply DBD::mysql to DBD::ODBC (target MS-SQL server). Of
> course that was a number of years ago.
>
> Thanks.
>
> Bill
>
>

This depends on the ODBC Driver - it was never a limitation of DBD::ODBC.

By default SQL Server did not used to support multiple active statements
if any of them were select statements. You could get around this by
changing to a dynamic cursor (I believe there is a setting in DBD::ODBC
to enable this and perhaps even a test case for it in the t subdir of
the distribution in 20SqlServer.t).

In MS SQL Server 2005, there is a new thing called MARS (Multiple Active
Result Sets) which allows multiple active select statements but it has
some nasty implications it you are also doing transactions.

For other drivers it depends. I believe Oracle ODBC driver does support
multiple active statements as myodbc does. Not sure about the rest.

If anyone wants to report success with a particular driver and multiple
active statements I will collect them and add a FAQ.

Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: DBD::ODBC multiple active statements (was Trouble InstallingDBD::ODBC with postgresql)

Martin Evans wrote:
>
> This depends on the ODBC Driver - it was never a limitation of DBD::ODBC.
With MS SQL, at least the versions <2000, it seems to be a low-level
protocol limitation. The Sybase protocol simply cannot handle more than
one active statement.
>
> By default SQL Server did not used to support multiple active
> statements if any of them were select statements. You could get around
> this by changing to a dynamic cursor (I believe there is a setting in
> DBD::ODBC to enable this and perhaps even a test case for it in the t
> subdir of the distribution in 20SqlServer.t).
I remember having had the same problem years ago, when "my" application
suddenly had to support MS SQL in addition to Oracle. I remember that
there was a problem with dynamic cursors, but I have forgotten if it
"only" required changing a few thousand lines of code in my application
or if there was a really ugly problem regarding transactions or the
number of dynamic cursors. Bill, please read the MS SQL documentation
about dynamic cursors extra carefully before deciding to go this way.

The workaround in my application was to use one general purpose ("main")
DB connection, and -- on demand and only if the database really needed
it -- a few auxillary connections that were/are restricted by contract
(i.e. documentation) to SELECT statements that MUST NOT affect
transactions on the main connection. A thin layer over DBI had
essentially two functions, one returning the main DB connection, and one
returning a named auxillary connection, creating a new connection for
each name. For databases like Oracle that support multiple connections,
even via DBD::ODBC, both functions simply returned the main DB connection.

>
> In MS SQL Server 2005, there is a new thing called MARS (Multiple
> Active Result Sets) which allows multiple active select statements but
> it has some nasty implications it you are also doing transactions.
I did not expect anything else from "Access on Steroids". ;-) (Ok,
that's only 50% MS bashing, the low level protocol has to be changed
quite dramatically to allow multiple active statements. Keeping it
backwards compatible must be a real pain.)

>
> For other drivers it depends. I believe Oracle ODBC driver does
> support multiple active statements as myodbc does. Not sure about the
> rest.
I think I've done lots of tests with Oracle 8, 9 vs. MS SQL 7, 8, 2000
to find out where the "bug" was that always popped up when trying to
have more than one active connection. I'm very sure I tested to connect
to Oracle via DBD::ODBC, and did not find the "bug". So DBD::ODBC and a
"recent" Oracle ODBC driver (everything newer than the archaeological
artefact Microsoft delivered up to at least Win2k) should support more
than one active connection. DBD::Oracle definately supports multiple
active statements. With PostgreSQL, the situation is nearly identically.
I did not explicitly test that for multiple active statements, but I use
it in code that needs them and it worked fine, both with PostgreSQL's
ODBC driver and the native DBD::Pg.

Alexander
>
> If anyone wants to report success with a particular driver and
> multiple active statements I will collect them and add a FAQ.
>
> Martin

--
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/