> 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
