On 25/10/10 11:40, Tim Bunce wrote:
> On Fri, Oct 22, 2010 at 06:59:57PM +0100, Martin J. Evans wrote:
>> I've released a DBD::ODBC requiring Perl 5.8 but included the use of
>> my_snprintf (from ppport.h) which unfortunately was not defined
>> until 5.9.4. Fair enough, my fault but I have no way of fixing it
>> (other than reversing my_snprintf back to sprintf) because of the
>> way DBI includes dbipport.h (alias ppport.h).
>>
>> In DBI, dbipport.h is a renamed ppport.h generated by Devel::PPPort
>> and is included from DBIXS.h which all DBDs include - presumably the
>> idea was to save DBDs from having to keep up to date with ppport.h.
>> In DBI 1.609, dbipport.h was updated (by H Merijn Brand I think) to
>> the latest Devel::PPPort 3.19 version but I'm not convinced
>> dbipport.h is always kept in sync with ppport.h. However, because
>> DBIXS.h includes dbipport.h as #include "dbipport.h" I cannot
>> override DBI's copy with a newer version in DBD::ODBC and hence I
>> cannot fix my my_snprintf issue the way I'd like which is to include
>> with DBD::ODBC a newer ppport.h as dbipport.h.
>>
>> In the case reported to me the user has an old DBI pre 1.609 which
>> has a massively out of date ppport.h and he cannot upgrade DBI but
>> he cannot install the latest DBD::ODBC. If that #include
>> "dbipport.h" was changed to #include <dbipport.h> I could at least
>> release a DBD::ODBC including the latest ppport.h as dbipport.h and
>> the problem is fixed. I know this won't help today but if this had
>> been done in the past I would at least have had the option to fix it
>> locally in DBD::ODBC today.
>>
>> As a result, I'd like to change that include in DBIXS.h to add this
>> flexibility in the future.
>>
>> Any objections?
> 
> None.

Done, thanks.

I didn't add a change entry. Sometimes I'm unsure whether to or not. In 
DBD::ODBC I pretty much log everything but I'm not sure of your policy in DBI.

> On Sat, Oct 23, 2010 at 10:53:20PM +0100, Martin J. Evans wrote:
>>
>> Given I've had no response to this (other than Tux on #dbi who did
>> not object) I will make the suggested change in the next few days (I
>> don't think it hurts but it allows DBDs to override the dbipport.h
>> with a newer version). However, since DBD::ODBC is broken with older
>> DBIs I'm going to make the next DBD::ODBC release dependent on DBI
>> 1.609.
> 
> Okay.

Also done in subversion but not released yet.

>> The next release of DBD::ODBC (1.26_1 only in subversion soon but
>> not as yet) has over 200 code block changes to the codebase mostly
>> to a) complete the move to ODBC 3.0 and require an ODBC Driver
>> Manager and b) refactor the code to remove redundant code.
>>
>> My next step is to investigate tracing as I'm having a lot of
>> problems with people settting the trace level to less than 15 or
>> setting a trace level for connections which is problematic.
> 
> Please explain (in a new thread).

Will do when I get a proper chance to research it fully.
 
>> The next development release of DBD::ODBC should be treated with
>> caution as it contains a huge number of codebase changes. I hope to
>> have this released in the next week.
> 
> Thanks Martin.
> 
> Tim.

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

Reply via email to