511 votes
Make SQL-Azure 100% T-SQL compatible
I script I maintain/exported from an on-premise site should just run on the cloud.
It doesn't matter if it implements some tokens as a No-OP or with warnings or notes. But it should compile unaltered and run on Azure.
Ahsan Mumtaz
It wont be possible to have 100% T -SQL compatibilty, because customer do not have direct access to the database. As we have T-SQL for our traditonal SQL Server (on premises)to create/monitor filegroup/datafile/logfile. But in SQL Azure customer do not have access of these atrbiutes, so no point to have T-SQL for thse attributes
pita.o
@DBman: & @Jamie: Thanks guys for your votes in support, especially Jamie, for whom this perhaps represents a significant rethink from the forum opinion on the same subject.
I've given a bit of thought to both comments; and am wondering ... perhaps, MSFT should
1. accept the conceptual idea of seeking to achieve full compatibility (not in the spirit of IE6, though)
2. Phase the implementation like:
(a) provide full syntactic compatibility for everything ... emit what you see fit for each ... more
@DBman: & @Jamie: Thanks guys for your votes in support, especially Jamie, for whom this perhaps represents a significant rethink from the forum opinion on the same subject.
I've given a bit of thought to both comments; and am wondering ... perhaps, MSFT should
1. accept the conceptual idea of seeking to achieve full compatibility (not in the spirit of IE6, though)
2. Phase the implementation like:
(a) provide full syntactic compatibility for everything ... emit what you see fit for each opcode
(b) provide semantic compatibility (with appropriate and well documented semantic equivalences where an exact match does not make sense) for DDLs (except stored procs, functions and such like)
(c) Do the best you can (with community input) for DMLs, stored procs, functions and such like.
MSFT already knows this to be a problem. The first (conceptual) cut they announced was a tooling approach. "Make SQL Management Studio smarter". I rather say, make the LEXER/PARSER smarter. This is not syntax coloring! It's a language issue. It should be addressed in the language.
Rajib Bahar
I'll 3rd it. It'll help us learn the technology easily.
Jamie Thomson
I'm totally in favour of as much T-SQL compatibility as possible (and I will be giving this idea 3 of my votes) but we must also face the reality that T-SQL as it exists today is not 100% compatible with SQL Azure.
I only know of one feature that is not compatible with SQL Azure but I'm pessimistically assuming there are more. The feature that I know about is SELECT...INTO. Every table created on SQL Azure requires a clustered index and the reasons for that are rooted in the high-availability mechanis... more
I'm totally in favour of as much T-SQL compatibility as possible (and I will be giving this idea 3 of my votes) but we must also face the reality that T-SQL as it exists today is not 100% compatible with SQL Azure.
I only know of one feature that is not compatible with SQL Azure but I'm pessimistically assuming there are more. The feature that I know about is SELECT...INTO. Every table created on SQL Azure requires a clustered index and the reasons for that are rooted in the high-availability mechanisms that SQL Azure provides. SELECT ... INTO creates heaps, hence not compatible with SQL Azure.
So, not 100% compatible but its mightily close. Nevertheless, even given what I just said this still gets maximum votes from me!
-Jamiet
DBman
I all for 100% T-SQL compatibility but it would be problematic to no-op unsupported T-SQL.
I assume that if my application sends a T-SQL statement to a server then the application probably depends on the correct execution of that statement to function correctly. If SQL Azure just ignores (no-ops) statements that are not supported then my applications may function syntactically but not semantically. For example, if you no-op the “use DB” statement my script will assume “use” worked but in reality I am ... more
I all for 100% T-SQL compatibility but it would be problematic to no-op unsupported T-SQL.
I assume that if my application sends a T-SQL statement to a server then the application probably depends on the correct execution of that statement to function correctly. If SQL Azure just ignores (no-ops) statements that are not supported then my applications may function syntactically but not semantically. For example, if you no-op the “use DB” statement my script will assume “use” worked but in reality I am still operating on the database before the execution of “use” – this may result in my scripts executing DDL on the wrong database.
I vote for 100% semantically correct T-SQL.