Dear Jeff,
Fair enough comments on using a driver manager.
I had tried to get iODBC up, but it barfed on a library I couldn't track
down - at run time, not compile/link time. I started on unixODBC too, but
then concluded I didn't want to confuse myself - or it, or iODBC - by
installing its libraries over the iODBC libraries, so I need to go back to
the drawing board and rebuild either or both DMs to install in separate
versioned directories (/usr/iodbc/v3.0.6/ and /usr/unixODBC/v2.2.3, I
think), reinstall, and generally sort out. I have a nasty feeling that
part of my problem with iODBC may be that I declined to build the GUI stuff
-- Solaris doesn't have the pre-requisites like Gtk installed -- yet the
library does not work properly without it. Untested hypothesis, but the
libiodbcadm was missing at run-time.
So, in the interests of expediency, I used the surrogate DM that is
distributed with Informix CLI - knowing it was less than ideal but being
unwilling to spend very much longer on getting set up.
I've just re-remembered why I find ODBC/CLI on Unix so painful! And that
is in no sense a comment on DBD::ODBC - just on ODBC in general on Unix. I
assume it is easier to deal with on MS platforms; at least, there's a
standard ODBC driver manager!
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Data Management Solutions
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
|---------+---------------------------->
| | "Jeff Urlwin" |
| | <jurlwin@bellatla|
| | ntic.net> |
| | |
| | 12/17/2002 08:16 |
| | PM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Jonathan Leffler/Menlo Park/IBM@IBMUS, "'Tim Bunce'"
<[EMAIL PROTECTED]>, "'Jeff Urlwin'" <[EMAIL PROTECTED]> |
| cc: "'DBI Users Mailing List'" <[EMAIL PROTECTED]>
|
| Subject: RE: Patch for DBD::ODBC 1.01 for using Informix CLI, etc.
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
> Dear Jeff and Tim,
>
> Here's a patch which more or less got DBD::ODBC 1.01 up and
> running using Informix CLI as the ODBC driver (and driver
> manager) on Solaris.
Jonathan -- that's GREAT! FYI -- I strongly encourage people to use a
driver manager, to simplify the building process. unixODBC has been
quite good for me.
>
> What did I have to fix?
>
> First of all, for some reason I don't understand fully, my
> system was initially diagnosed as being a udbc system. So, I
> had to hack Makefile.PL to avoid that mis-diagnosis. In
> doing so, I cleaned up the testing for other drivers and made
> it all more consistent. Then I added a test which heads off
> trouble when no valid ODBC system is detected. There's now a
> list of the ODBC drivers which are supported; this is printed
> when no valid system is detected.
Thanks. That needed work, as you know. I only test with a few
different ODBC drivers/managers and mostly have accepted nearly all
patches provided. I *really* appreciate the cleanup.
>
> Then I had to fiddle the definitions for use with Informix
> CLI, which was no worse than any other driver. I made sure
> that the detailed version and platform information for
> Informix is in the file. It will gently get out of date, but
> can be brought up to date again as necessary. It at least
> tells people where it was originally thought to work.
Good -- nothing out of the ordinary.
>
> I'm using a butchered DBI 1.32 that is masquerading as 1.33,
> and it showed up a couple of minor problems in dbdimp.h -- no
> #define for dbd_discon_all and a stray #define for dbd_db_do.
> Tim may yet decide those changes are too radical for DBI
> 1.33, but this change will allow your driver to work with
> both existing DBI versions and the future version where all
> the functions in Driver.xst are guarded with #ifdef's. Note
> that DBI 1.32 and earlier does not ever call dbd_db_do.
>
That might be an issue, though. I might prefer to wait until the
release version or things settle on the DBI internals...depending upon
what Tim says.
I now see the problem with the dbd_db_do and the dbd_discon_all issues.
I have a do() replacement that starts in Perl and calls
dbd_db_execdirect. I suppose I could rework it to use the do, but as
you pointed out, it's not called, so I'll leave it.
> I modified one (of three) calls to SQLDescribeCols() so that
> GCC didn't witter at me about incompatible pointer types. I
> used an effective but crude technique; I declared a local
> variable of the correct type and passed that to the function,
> and then assigned the variable to the original source of
> trouble. It was the ColumnSize parameter (7), which was
> being given a U32 pointer but the ODBC specs say it should be
> an SQLUINTEGER pointer.
Yes, I just end up ignoring those, but I should probably go in and clean
them up someday. Some platforms may care...
>
> I ran into a problem with t/02simple.t; there was no newline
> at the end of the output from test 9, so the 'not ok 9' was
> getting lost. That was easy to fix. With that fix in place,
> I was getting two test failures, numbers 6 and 9 in
> t/02simple.t. I wondered if it was my slightly unusual
> setting of the (Informix-specific) DBDATE variable that was
> throwing things for a wobbly, but it does not appear to be
> that. I'm not sure how much time to spend debugging that -
> get back to me on it. The verbose output from the test that
> is failing (with the extra newline in place) is in the second
> attachment.
Hmm...it looks like some null chars are being retrieved with the data
and that's throwing the test off. I'm somewhat surprised that more
tests didn't fail, given the data discrepancy...maybe I need to update
my tests :)
Test 9 is failing because of some strange results on the col attributes.
I'm wondering if the same null character issue is the source.
Here's the output from Oracle.
Column count is: 4
1: COL_A = 3 3 yes
2: COL_B = 12 12 yes
3: COL_C = -1 -1 yes
4: COL_D = 93 93 yes
Here's the output from your sample (normally the yes means a match is
found with grep()), so, adding carriage returns for clarity:
1: col_a = 5 5
2: col_b = 12 12
3: col_c = -1 -1
4: col_d = 93 93
For some reason, grep with $coltype == $_ isn't matching any of the test
types -- while it should. I am thinking that a trailing null on data
returned is forcing Perl to see the numbers as characters...
>
> I wrote README.informix with much of the same information in
> it. Feel free to remove the first paragraph if you accept
> the patches I'm sending. Amongst other things, it documents
> that DBD::ODBC does not manage to handle Informix's
> non-transactional databases -- I got many more failures until
> I used a logged database.
Ok -- I'm certainly not an Informix person, so I'll take your word for
it. I specifically test transactions and AutoCommit support, so I can
see if commit and rollback don't work, a lot of tests will fail.
>
> I also hacked the README (carefully preserving the DOS line
> endings) to update the rather archaic URLs and instructions
> for joining the mailing lists.
Thanks! I normally move things over to *nix line endings, but the
README I had specifically left so that a person on Windows with Notepad
could read it. I get painful results with native editors under
Win32...I use Epsilon which can preserve whatever line endings in the
files, so I don't tend to notice.
>
> With luck, I can now generate a GetInfo module for DBD::Informix!
>
Great!
I'm concerned about the nulls at the end of the strings retrieved. I
believe that's causing the issues with the tests, although the tests
should be a bit more picky.
Thanks!
Jeff
