> Why not have something like this:
>
> server: &server
> driver: /opt/local/whatever-driver.so # or whatever
> user: my_login
> password: M$_wh0r3
> server: 192.168.2.666
> tds_version: 8.0 # if anyone needs this
>
> development:
> database: rails_
On 1/29/06, Tom Ward <[EMAIL PROTECTED]> wrote:
> As you can see, you can pass a full connection string as the dsn. I'd
> like to factor the common parameters out of this string (server, db,
> password, user) and use standard yaml
> attributes to specify them, but I need to check how this will aff
> > Unless people have significant objections, I'll create a ticket and
> > patch to deprecate ADO, and update the wiki instruction pages
> > accordingly.
>
> I don't really know enough about SQLServer to object. I know that I
> had to install the ADO driver to connect to one of my client's
> serve
> So what do people think? Does ADO have advantages over ODBC I'm not
> aware of? Are there other reasons to keep ADO support in the adapter?
>
> Unless people have significant objections, I'll create a ticket and
> patch to deprecate ADO, and update the wiki instruction pages
> accordingly.
I d
The SQL Server adapter can currently operate in two modes, ADO and
ODBC, each of which uses a different interface to access the db. The
ADO interface is currently the default, while ODBC can be specified as
an option.
I propose this situation is reversed, and that use of the ADO
interface is depr