Ed Belisle wrote: > 1. Yes. All I need to do is detect errors. If there's no error, > excecution continues.
I hope for a discussion at dbi-dev: <http://www.xray.mpe.mpg.de/mailing-lists/dbi/2004-01/msg00204.html> > My current workaround is to shell these commands to osql. Doesn't local $dbh->{RaiseError} = 0; or eval { ... } work? > 2. Why do I connect to SQL Server via ADO via ODBC? Am I? I thought I > was just using ADO. The short answer is I've only been doing PERL for a > year and this worked. The long answer is I'm changing databases from > mySQL to SQL Server, and the SQL Server examples I had to work with all > had ODBC sources set up in Control Panel | Data Sources, and I found I > could be more dynamic with ADO. AFAIK, you have the following alternatives to connect to SQL Server: - DBD::Sybase - DBD::FreeTDS - DBD::ODBC - DBD::ADO With DBD::ADO, you can use - OLE DB Provider for SQL Server (Provider=SQLOLEDB) - OLE DB Provider for ODBC Drivers (Provider=MSDASQL) MSDASQL is the default provider for ADO (if you omit Provider=). Consider how many layers are involved in every case! Each layer mangles (or even drops) some (meta-)data. I cannot speak for SQL Server, but for Oracle I always use DBD::Oracle, never ADO or ODBC. For more connection string examples, see e.g. <http://www.able-consulting.com/ADO_Conn.htm> > [...] > > 3. Additional bug in ADO. Thanks for reporting this. > SELECT max(A), max(B) from DATATABLE will > return the one row with the same value repeated. ($row[0] eq $row[1]) I > figure this happens because the values returned are stored in a hash, Nearly. Every fetch return a Fields collection from the RecordSet internally. This OLE collection is accessed *like a hash*: $rs->Fields( $_->{Name} ) But it can be accessed like an array too: Win32::OLE::in( $rs->Fields ) I put this on my TODO list. > and both column titles are empty. Most DBMS generate names for the expressions, some guarantee uniqueness. > My workaround is to name all > calcuated fields and the problem goes away. In hindsite, it's a bad > practice to reference results by ordinal instead of named values. Indeed, SQL fails to *require* unique column names - see e.g. 'The Importance of Column Names' by Hugh Darwen: <http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Importance-of-Column-Names.pdf> Steffen
