Actually, last night I JUST figured out a solution.  I wrapped all of my connection.select_alls in connection.transactions. Done. Somehow, Rails closes the objects properly for SQL Server when I do that.

Hopefully that helps someone. :-)

-----Original Message-----
From: Dejan Dimic [mailto:dejan.dimic / gmail.com] 
Sent: Tuesday, September 09, 2008 3:19 AM
To: ruby-talk ML
Subject: Re: Connecting to SQL Server
Importance: High

On Sep 4, 2:20   Į 㮮 
> So ActiveRecord has failed me. The sqlserver module isn't complete, and
> I'm getting "zombie state" errors, essentially because Rails wants to
> maintain a connection to SQL server and SQL server is used to ASP.net
> making connections to the server for every request. (Yuck, but that's
> what I have to work with here.) Is there a ruby gem that's been
> maintained to use SQL Server better? I can't find one, but someone's
> gotta be working on one with how common SQL Server is.
>
> I don't even use most of the "cool" features ActiveRecord has as I have
> a DBA here who insists on using stored procedures for everything. That's
> an industry standard, but not the Rails way, and thus another roadblock
> in my Rails application.
>
> If there isn't anything, I'll research creating my own gem to do the
> task. Obviously I'd rather not duplicate efforts. Thanks!
>
> Clinton Judy
>
> Web Developer
>
> Glenn O. Hawbaker, Inc.

I am too often in same situation. For this I use the activerecord-
sqlserver-adapter.
Kipping the business logic in SQL stored procedures is a product of
one development school.
Do not want to enter in discussion about pros and cons of that
decision but it's a reality of life.
Thing that bother me even more is a column naming convention that is
usually used in MS SQL databases.
In almost all my Models has to explicitly define a table name and a
primary key name.

However, I have managed to communicate with MS SQL in satisfactory
faction.