Without allowing SELECT INTO in order to at least create an EMPTY table (which can then have a clustered index created, etc) makes Azure, in practical terms, unusable for our purposes.
Even better, why couldn't MS provide a T-SQL query to retrieve what Management Studio returns in "Script As"? You obviously already have the code (in SSMS) so why couldn't you have made this scripting available on SQL Server itself through a query interface (like Oracle does)? We've had to reinvent the wheel in order to create our own such functionality and it's caused a maintenance nightmare.
I understand that SELET INTO is not supported in SQL Azure standard tables because that will create a new table that doesnt have the clustered index needed to replicate the data correctly.
However, when creating tables in the tempdb you can create tables without a clustered index - and so the SELECT INTO command should be able to be used when the output table is stored in the TempDB.
99% of all my SELECT INTO are used for temporary tables (to increase speed in reporting and data processing)
Thanks for your feedback. We now have the next generation of Azure SQL DB in public preview in the US and GA in Europe.
Specifically it supports Select Into.
Details here http://azure.microsoft.com/blog/2014/12/11/preview-available-for-next-generation-of-azure-sql-database/
Jordan B commented
Looks like the new Azure DB Update preview has this problem resolved:
> The V12 preview enables you to create a table that has no clustered
> index. This feature is especially helpful for its support of the T-SQL
> SELECT...INTO statement which creates a table from a query result.
As Kevin Chamberlain suggested, why not at least allow a SELECT INTO with 0 rows to enable creating just the table structure. Would have been enormously helpful for us. Will wait for Azure to mature a little more.
Jonathan Winata commented
The lack of this feature is a major inconvenience for us since we are using the temp table for data validation during bulk imports.
Jordan B. commented
I get why this is the case with Azure tables requiring clustered indexes for replication and whatnot, but why on earth enforce this restriction for temp tables? Select Into statements are widely used in my organization for generic dynamic triggers. Knowing the exact column definition is one thing, but this restriction creates a significant maintenance liability.
Jim Pelletier commented
This feature gap has been a major inconvenience for our company as well. If I could give it more votes, I would.
Kevin Chamberlain commented
Additionally it would be really nice to allow a select into where no data is being inserted into the table. This is often used to establish a table (or # table) structure that is dynamically generated first, then populated so system objects aren't being locked while the data from the select is being gathered to put into the table. This would then allow us to 1. Create a table dynamically, 2. Create the clustered key, 3. Populate the table from the query.