[unixODBC-support] Stored procedure messages returned in reverse cron order from DBD::ODBC mssql/EasySoft

eric.berg at barclayscapital.com eric.berg at barclayscapital.com
Wed Jul 27 20:53:38 BST 2011

Thanks for that complete answer.  This hits up against something that I think we did dead wrong in our internal packaging of the EasySoft ODBC drivers, which was to put odbc_config into /usr/bin.  That means that a 2005 version (2.11) of odbc_config is going to be in the official path once our EasySoft package is installed onto our hosts.  Clearly this poses a conflict.

A rebuild of DBD::ODBC using the recommended parameters fixed the problem, but it's just lucky that I've been cracking my head against these issues constently for several months now, because a less-abused guy might have missed this.

I'm sure our packaging engineering guys will get right on this, since it's either that support the chaos that ensues.

Thanks again.



> -----Original Message-----
> From: Martin J. Evans [mailto:martin.evans at easysoft.com]
> Sent: Wednesday, July 27, 2011 2:58 PM
> To: Berg, Eric: IT (NYK)
> Cc: bohica at ntlworld.com; unixodbc-support at mailman.unixodbc.org; PointDB
> Support
> Subject: Re: [unixODBC-support] Stored procedure messages returned in
> reverse cron order from DBD::ODBC mssql/EasySoft
> On 27/07/2011 19:38, eric.berg at barclayscapital.com wrote:
> > Hey, thanks, Martin.
> >
> > It's super simple.  Here you go:
> >
> > my $dbh = DBI->connect(....);
> > my $sth = $dbh->prepare("exec workdb..HS_post_message2");
> > my $rs = $sth->execute;
> > warn "Execute done.";
> >
> > Thanks again.  I'll check in with you tomorrow.
> >
> > Hey, while I've got your attention, a little while ago when we were
> dealing with the last segfault issue, Richard suggested that I add "-
> DSIZEOF_LONG=8 -DBUILD_REAL_64_BIT_MODE" to the CFLAGS line in the
> generated makefile, and that's been very helpful.  What can we do about
> fixing DBD::ODBC to avoid having to do this manually every time.  This
> afternoon, for example, I did a cpan update of a bunch of modules and
> immediately we started seeing the segfault issue again, because cpanplus
> thought we needed to update dbd.odbc.
> >
> > Thanks!
> >
> > Eric
> DBD::ODBC already supports this BUT it needs a newish unixODBC which
> installs with the odbc_config program
> What DBD::ODBC does, is attempt to locate odbc_config on your path and
> then runs it with the --cflags argument which should return the correct
> -D arguments to build DBD::ODBC in the same way as unixODBC was built
> with. DBD::ODBC adds these args to the compiler line. If you have an
> older unixODBC (say as installed by default from some Linux Debian
> packages e.g., Ubuntu) it does not have odbc_config (I've tried to
> contact the debian maintainers to get them to update unixODBC but I've
> got nowhere so far). Also, until some date XXX (Nick will know better
> than me) Easysoft did not distribute a modern enough unixODBC with their
> distributions. I believe this is rectified now.
> I'm not too sure about the -DBUILD_REAL_64_BIT_MODE - if it is returned
> by odbc_config --cflags DBD::ODBC will use it but I forget right now
> what this means. I will ask Nick tomorrow as I'm not sure that is needed.
> FYI, If you don't have odbc_config program then the header files
> distributed by unixODBC rely on SIZEOF_LONG being defined to get the
> right long size (the configure program defines this when unixODBC is
> built from source). If you build a program against unixODBC headers for
> a unixODBC which was built with SIZEOF_LONG=8 and don't set
> SIZEOF_LONG=8 you get SIZEOF_LONG=4 by default and you'll get a
> mismatched program and unixODBC which leads to all sorts of problems.
> Basically, this should be a non problem now so long as you have a
> recentish unixODBC with odbc_config program installed.
> So, if you hit this again today, look for the odbc_config program. If
> you have not got it (or --cflags does not output anything) you need to
> update unixODBC to a newer version and DBD::ODBC should do the right
> thing. If you have a scenario which does not seem to match what I'm
> saying mail me privately and I'll look into it.
> Martin

This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays Group.

More information about the unixODBC-support mailing list