Some people have put in some initial work, and I think it's in the repository. Proprietary databases are hard to support, and so far people interested in developing that support have tended to wander off. There is Sybase support, which should be similar to MSSQL due to their common ancestry. I personally wouldn't work on it unless there was something work-related requiring it (and if I'm involved in the technical decisions, I'd actively avoid MSSQL anyway); while I would help SQLObject support any open source database, even if I didn't use it, I put very little priority on integrating with proprietary software.
> I'd actively avoid MSSQL...
> while I would help SQLObject support any open source database, even if I didn't use it, I put very little priority on integrating with proprietary software
I respect your objection to using MSSQL. I even agree with you to a point (PostgreSQL is great!), although MSSQL has some very nice features including extremely nice administration tools...but we won't get into that discussion.
Moving on... Can you see value in allowing people to use SQLObject by providing an easy way to connect to MSSQL? It certainly doesn't hurt SQLObject to have easy integration with MSSQL. I'd even argue that it will improve the market share of SQLObject to have that connector built in and ready to go. The last thing most developers want (or have the ability) to change when they are working on a database project is the persistence layer. That means that most people who are currently using MSSQL and looking for a Python ORM will pass over SQLObject because it doesn't work with MSSQL. You can hardly deny that Microsoft has a LOT of market share, which means that a lot of people won't be using SQLObject until there is an easy way to use it with MSSQL.
I'm not going to stop anyone. I'll even help, to some degree (maybe just a small one). But features like this need a champion, and I definitely won't be that champion.# Ian Bicking