Simon Oliver wrote: > Why isn't it on CPAN as a distinct archive, or at least as a download from > sap.com?
It isn't on CPAN (and never will be) because it depends on internal sapdb sourcefiles that are not distributed as part of the normal distribution, it uses an undocumented internal interface. It is not available as a download because: 1) It has been deprecated. 2) It was/is a part of the scriptif package. > What advantages are there for using DBD::SAP_DB rather than the ODBC drivers? None. In fact, there has never been a working binary DBD::SAP_DB, I've had to patch and compile it for every release to get a (semi)working driver. As far as I can tell using DBD::ODBC compiled directly against the sapdb odbc interface is as fast or faster than DBD::SAP_DB and because it works correctly when using connect_cached it is *a lot* faster when it's being used from a webserver. I've worked for almost a year trying to make DBD::SAP_DB stable, but it never happened, I got DBD::ODBC to work near-flawlessly in just a few hours. Using DBD::ODBC is a good idea because: 1) the sapdb odbc interface is the official interface to sapdb, so there is a good chance that any bugs or performance issues will be addressed. 2) The DBD::ODBC driver is used by *many* different databases on a lot of different platforms by a lot of different people, so any bugs will be fixed quickly. The SAPDB speciffic lines in DBD::ODBC is less than 20 lines and most of it is the autoconfiguration code I wrote to make it use the sapdb driver directly, if you use a drivermaneger then no code in DBD::ODBC needs to be changed. The only issue with DBD::ODBC is that you need to recompile the sapdb odbc interface with debugging information turned on or it will segfault the client on connect. -- Regards Flemming Frandsen aka. Dion/Swamp http://dion.swamp.dk
