Re: Differences with methods to access SQL Server 2000.

No, you want to use DBI;. Here are the key pieces:

DBD:ODBC (as mentioned)
Some ODBC-ODBC bridge software

If memory serves me, MSSQL::*, Sybperl::*, Oraperl::*, etc. are all precursors to the DBI. It's been done. And while we all complain, it was because it's not an easy task. But I haven't heard anyone say they didn't get it to work.

ALL HAIL BRAK!!!

Comment on Re: Differences with methods to access SQL Server 2000. Download Code

Replies are listed 'Best First'.
Re: Re: Differences with methods to access SQL Server 2000. by tinman (Curate) on Apr 20, 2001 at 20:06 UTC
From some experience trying to interface with MS-SQL 2000 with Perl, these are the things that I've discovered.. MSSQL::* libraries don't work from Unix.. I may have looked at an outdated version of the pages, but this page is what I saw and it wasn't very encouraging about working on Unix, or getting these libraries to work with SQL server 2000. DBD::ODBC as mentioned above, worked well for me..I'd really not advise using something like DBD::Proxy, although that is indeed one option, because of the potential heavy traffic... instead use a Unix ODBC bridge such as iODBC in conjunction with DBD::ODBC... it may not be the fastest, perhaps.. but on what I implemented, it survived a load test of 150 concurrent users with no problems.. HTH	[reply]

Replies are listed 'Best First'.

Re: Re: Differences with methods to access SQL Server 2000.
by tinman (Curate) on Apr 20, 2001 at 20:06 UTC

From some experience trying to interface with MS-SQL 2000 with Perl, these are the things that I've discovered..

MSSQL::* libraries don't work from Unix.. I may have looked at an outdated version of the pages, but this page is what I saw and it wasn't very encouraging about working on Unix, or getting these libraries to work with SQL server 2000.

DBD::ODBC as mentioned above, worked well for me..I'd really not advise using something like DBD::Proxy, although that is indeed one option, because of the potential heavy traffic... instead use a Unix ODBC bridge such as iODBC in conjunction with DBD::ODBC... it may not be the fastest, perhaps.. but on what I implemented, it survived a load test of 150 concurrent users with no problems..
HTH

[reply]