Re: CREATE DATABASE fails in DBD::ADO 2.75-2.83
From: Steffen Goeldner (sgoeldner_at_cpan.org)
Date: 01/12/04
- Next message: David Garamond: "inserting strings with NUL chars using DBD::Pg?"
- Previous message: Peter J. Holzer: "Re: UNSUBSCRIBING (WAS: RE: ANNOUNCE: DBI 1.40)"
- Maybe in reply to: Steffen Goeldner: "Re: CREATE DATABASE fails in DBD::ADO 2.75-2.83"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 12 Jan 2004 16:18:07 +0100 To: <ebelisle@ix.netcom.com>
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
- Next message: David Garamond: "inserting strings with NUL chars using DBD::Pg?"
- Previous message: Peter J. Holzer: "Re: UNSUBSCRIBING (WAS: RE: ANNOUNCE: DBI 1.40)"
- Maybe in reply to: Steffen Goeldner: "Re: CREATE DATABASE fails in DBD::ADO 2.75-2.83"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
