blowdart said:Bass said:*snip*
why should I write properitary database code such as T-SQL which will ensure my code will never work with more then one database and operating system?
You don't have to, frankly 99.9% of the time you don't need the T-SQL extensions, and that's what they are, extensions. Ditto with Oracle. If you think that you can't run SQL-99 on Sql Server then your research hasn't been that deep, especially as MySQL only supports a SUBSET of Sql99 and indeed has it's own proprietary extensions and states "We are not afraid to add extensions to SQL or support for non-SQL features if this greatly increases the usability of MySQL Server for a large segment of our user base."
I really don't ever want to have to say "No, you can't" to a high paying customer just because his infrastructure and my code don't work together. That's why portability is important to me, in my industry there exists no monoculture where everyone uses Windows and SQL Server.
Saying you only support a single database is not portability. Simply because your chosen database runs across X OS's is not going to endear you to large customers who already have an investment in a database system other than your chosen one. Rather than support a single database abstract it, provider models, ORMs that support multiple backends. Far more flexible and gives you a larger market to sell into.
Perhaps I was misunderstood, I (so far) want to support multiple databases, and do so, by writing simple SQL-99 that should work on all major databases. I will look into ORMs as well. I'm asking what the advantage of writing T-SQL is, is it worth losing portability over? It baffles me because there are companies who sell products that only work with one database.