Re: apr_dbd_freetds

[Nick Kew <ni...@apache.org>]

On 22 Aug 2012, at 18:18, Nick Kew wrote:

> Is anyone in a position to take up the baton on FreeTDS?
> 
> If not, perhaps it's time we dropped that driver in favour
> of the ODBC one.

In addition to this thread, I recently raised this on the PMC list.

I'm now proposing to turn talk into action.  That is to say, unless
someone comes up with a reasoned argument to retain it,
I'll delete it from SVN.  It'll still be in the archives for anyone
who wants it, and it is of course open to anyone to step up
as maintainer from your own site, or from a general-purpose
developer site like sourceforge or github.

I'd expect an argument to retain it to address current bugs,
future maintenance, and the problem of prepared statements.

-- 
Nick Kew

Re: apr_dbd_freetds

[Nick Kew <ni...@apache.org>]

On Thu, 7 Mar 2013 18:56:38 +0200
Graham Leggett <mi...@sharp.fm> wrote:


> There is a workable alternative driver for end users in the form of the ODBC driver (to my understanding), so removing it doesn't leave end users in the lurch.
> 
> Can we make sure the removal is documented, and people pointed at the alternative solution?

Yep, that's the general intention.

Thanks for mentioning the ODBC.  I meant to say that,
but forgot when I posted.


-- 
Nick Kew

Re: apr_dbd_freetds

[Graham Leggett <mi...@sharp.fm>]

On 07 Mar 2013, at 6:50 PM, Nick Kew <ni...@apache.org> wrote:

>> Is anyone in a position to take up the baton on FreeTDS?
>> 
>> If not, perhaps it's time we dropped that driver in favour
>> of the ODBC one.
> 
> In addition to this thread, I recently raised this on the PMC list.
> 
> I'm now proposing to turn talk into action.  That is to say, unless
> someone comes up with a reasoned argument to retain it,
> I'll delete it from SVN.  It'll still be in the archives for anyone
> who wants it, and it is of course open to anyone to step up
> as maintainer from your own site, or from a general-purpose
> developer site like sourceforge or github.
> 
> I'd expect an argument to retain it to address current bugs,
> future maintenance, and the problem of prepared statements.

There is a workable alternative driver for end users in the form of the ODBC driver (to my understanding), so removing it doesn't leave end users in the lurch.

Can we make sure the removal is documented, and people pointed at the alternative solution?

Regards,
Graham
--