I’m a software engineer in a Microsoft dominated company and now and then whilst between larger projects I am asked to create support for those larger projects. This will almost always involve some form of database interaction and being dominated by Microsoft technology our database of choice is of course Microsoft SQL Server. This makes developing support applications in non-Microsoft languages a real problem.
I’ve looked at Smalltalk, Go, Scheme and Factor and I always come to the same conclusion that it just isn’t possible or worth the effort because ODBC support for those languages is just to fragile to be useful.
I’ve investigated the possibilities of creating a data access layer via a web service. This is not always the ideal situation though and with large amounts of data this can turn out to be a bottle neck.
I could clone the data and import it into a more open database system and then develop in a language of my choice. This seems like a very unnecessary step and also means that I am no longer working with primary data.
How are other C# .Net developers developing support applications that rely heavily on the Microsoft stack in non-Microsoft languages?
Instead of going the ODBC route, you might consider using native drivers in whatever language you pick. This will probably “fit” better with that language’s approach. For example, Python has pymssql and cx_oracle which each conform more closely to the conventions of the language rather than trying to force it into least-common-denominator of ODBC. I’m not familiar with the languages you listed (and it’s not clear if you’re limiting this question only to those), but I suspect a similar situation exists there.
FreeTDS also comes up a lot in discussions of SQL Server access, but mostly from a Linux perspective.
Another variation: if you use something that uses the .Net DLR such as IronPython or IronRuby, you get to use the .Net Framework and it’s ADO.NET libraries while still applying a new language approach.