> > DBD::Sybase *will* work with FreeTDS (mostly), although > recent versions of DBD::Sybase implement a lot of things that > don't exist in the FreeTDS libs (yet), such as RPC calls for > stored procedures, text/image updating via ct_send_data(), etc. > > > Is it that you want to dedicate more of your time to > FreeTDS part and > > not being bothered with the Sybase/MS SQL part? Can't you > just ignore > > the Sybase posts? > > Actually it's the other way around. I get a lot of email for > problems that are inherent to the FreeTDS libs, not to > DBD::Sybase. For example DBD::Sybase's "make test" fails in a > *lot* of places when used with FreeTDS (although it is > getting better). A DBD::FreeTDS module would avoid this, and > failures in "make test" would at least indicate real problems. > > > I do not see into the technical differences and it might be > that new > > versions of MS SQL will not work with FreeTDS libraries at all. But > > still, for me FreeTDS libraries and DBD::Sybase did a great job and > > I'd like it to continue, if possible. > > It will - DBD::FreeTDS would not be a replacement from > DBD::Sybase+FreeTDS, it would be an alternative. FreeTDS is > still being improved of course, and gets closer in behavior > to Sybase's OpenClient. But I don't want to have to modify > DBD::Sybase too much to map to > (possible) idiosyncracies in FreeTDS. And of course we still > have the case where both Sybase and MS-SQL access is required > from the same script, and the FreeTDS support isn't deemed sufficient.
IMHO, of course: >From the outside in (I too get questions about DBD::ODBC and FreeTDS, but probably not as often as you): I would think that it would be worse, overall, to have two modules. I think it would be [potentially] better to have the ability to detect whether you're using FreeTDS or true sybase libraries and have the tests (and possibly the code) adjust themselves. This is coming from me guessing that the majority of noise level is due to the tests failing rather than someone's real code. In DBD::ODBC I've started to go down the path of skipping tests and announcing the reason why I skipped it. In fact, I now have SQLServer and Oracle specific tests only because I really can't test using a stored proc without creating it first and knowing how to create it is dependant upon where I'm connected. So, I started down a path where I have some tests run an some not run based upon the database. I've expanded it to add tests that are database dependant, where people have sent bug reports. So t\foo.t has some tests which are skipped if Oracle or Access, etc, and I have whole test files t\20SqlServer.t which do nothing if not connected to SQL Server (for example). Just a suggestion, but might that be easier?? Regards, Jeff
