Re: DBD::Oracle installation on AIX

"Martin J. Evans" <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.general
Organization at home
Message-ID <[email protected]>
On 23/09/2013 18:43, Nagendra Singh wrote:
> Thanks Martin.
> How can I get UnixODBC trace? Could you please let me know the command.
> Strange thing is on one Linux machine its working fine and on another
> Linux machine( Same configuration) its not.
> Result of odbcinst-j is:-
> UnixODBC2.2.14
> Drivers:  /etc/odbcinst.ini
> SYSTEm Data Sources /etc/odbc.ini
> File DataSources : /etc/ODBCDataSources
> User Data Sources: /etc/odbc.ini
> SQLUEN Size:8
> SQLLEN Sixe : 8
> SQLSETPOSIROW Size:8
> Regards,
> Mr. Singh

Could you please keep dbi-users list on the cc list of your emails as 
other people might be able to help.

Also, top posting (putting your reply above mine) makes it hard for 
people to follow.

Your odbcinst output shows you are using unixODBC on a 64 bit platform 
built with the ODBC type SQLLEN set to 8 bytes. If your driver was built 
with SQLLEN set to 4 bytes it can lead to all sorts of difficult to 
track down problems.

To get a unixODBC trace you look at the odbcinst -j output and find the 
file pointed to by:

Drivers:  /etc/odbcinst.ini

At the top of this file you add the following:

[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log

which tells unixODBC to trace all ODBC calls to the file 
/tmp/unixodbc.log. You then run the smallest script which produces the 
error and look in /tmp/unixodbc.log. It will show each ODBC API call, 
what arguments were passed and what was returned. However, I'm currently 
of the opinion this won't help us much as either:

a) your ODBC driver is broken
b) it was built with SQLLEN 4 bytes instead of 8 bytes

Neither of (a) or (b) DBD::ODBC can do anything about and both would 
require you contacting vertica to get a fixed ODBC driver.

Martin
-- 
Martin J. Evans
Wetherby, UK

>
> *From:* Martin J. Evans <[email protected]>
> *To:* Nagendra Singh <[email protected]>
> *Cc:* "[email protected]" <[email protected]>
> *Sent:* Monday, September 23, 2013 12:32 PM
> *Subject:* Re: DBD::Oracle installation on AIX
>
> On 22/09/2013 22:41, Nagendra Singh wrote:
>  > Hi Martin,
>  > Thanks a bunch for looking into this problem. Here are the details asked
>  > by you:-
>  > PERL Version is v5.10.1
>  > DBI Version is 1.609
>  > DBD::ODBC version is 1.43.
>  > Logs file are attached.
>  > Regards,
>  > Mr. Singh
>
> Thank you for the trace file. Your versions above should be ok.
>
> You DBI_TRACE shows:
>
> !SQLError(26b11a0,26b1320,0) = (82, 0, 523 80)
>            ^^^^^^^ environment handle
>                    ^^^^^^^ connection handle
>                            ^ statement handle
> and the (82, 0, 523 80) are:
>
> sql state,
> native error,
> error message
>
> '82' is not a valid ODBC state - it should be 5 characters.
> 0 as a native error is unusual but not an error.
> '523 80' is peculiar as an error msg.
>
> None of this is enough for me to diagnose any problem other than your
> ODBC driver seems broken or is perhaps using an incompatible ODBC API
> (e.g., one where DBD::ODBC was built with SQLLEN as 64 bit and vertica
> was built with SQLLEN 32 bit).
>
> You will need to contact Vertica I guess. You might want to ask them:
>
> a) why the state is only 2 chrs
> b) what error msg '523 80' means
> c) whether their ODBC driver was built with 32 bit or 64 bit SQLLEN
>      run odbcinst -j on your machine to see how unixODBC was built.
> d) include a unixODBC trace - which by the way, the one you sent me was
> not a unixodbc trace - it was the start of the DBI trace.
>
> Martin
> --
> Martin J. Evans
> Wetherby, UK
>
>  > *From:* Martin J. Evans <[email protected]
> <mailto:[email protected]>>
>  > *To:* Nagendra Singh <[email protected] <mailto:[email protected]>>
>  > *Cc:* Michael Nhan <[email protected]
> <mailto:[email protected]>>; Manimegalai Visvanathan
>  > <[email protected] <mailto:[email protected]>>;
> "'[email protected] <mailto:[email protected]>'" <[email protected]
> <mailto:[email protected]>>
>  > *Sent:* Sunday, September 22, 2013 11:51 AM
>  > *Subject:* Re: DBD::Oracle installation on AIX
>  >
>  > On 21/09/2013 19:42, Nagendra Singh wrote:
>  >  > Hi,
>  >  > I have installed DBD::ODBC latest version on 64 bit Linux Machine. One
>  >  > one machine I am able to make connection to Vertica using DSN but on
>  >  > other machine I am getting following error message. My odbc.ini,
>  >  > odbcinst.ini files are matching exactly:-
>  >  > set_err:State('82') is not a 5 character string, using 's1000' instead
>  >  > at /usr/local/lib64/perl5/DBD/ODBC.pm line 153. DBI
>  >  > connect('VertcaiABITPRIM','nbxxxxx',...)failed: 523 80 (SQL-82).
>  >  > Any pointer would be appreciated.
>  >  > Regards,
>  >  > Mr. Singh
>  >
>  > What version of Perl, DBI and DBD::ODBC are you using (latest does not
>  > help as new versions have recently been released))? You can generally
>  > get these using:
>  >
>  > perl --version
>  > perl -MDBI -le 'print $DBI::VERSION'
>  > perl -MDBD::ODBC -le 'print $DBD::ODBC::VERSION'
>  >
>  > Error state '82' is not a 5 character string and ODBC states should be.
>  > It might also be useful if you can provide any details of the Vertica
>  > ODBC Driver. S1000 is now HY000 which is a general error and should be
>  > accompanied with some error string.
>  >
>  > Error '82' (even 82000) does not exist. Error code 08002 does exist and
>  > that can be found here ->
>  >
> http://www.easysoft.com/developer/interfaces/odbc/sqlstate_status_return_codes.html#08002
>  >
>  > If you are using a recent DBI and DBD::ODBC you can do:
>  >
>  > DBI_TRACE=DBD=x.log perl myprogram.pl <http://myprogram.pl/>
> <http://myprogram.pl/>
>  >
>  > and x.log should contain the log of odbc calls which would help me
>  > identify your problem. If this file ends up empty, try again with:
>  >
>  > DBI_TRACE=15=x.log perl myprogram.pl
>  >
>  > Martin
>  > -- Martin J. Evans
>  > Wetherby, UK
>  >
>  >
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.