locked
Feedback to the SQL Azure Team RRS feed

  • General discussion

  • We are interested in your wish list for new features -- a usage scenario for the new feature would help us understand the context of your needs

    We are interested in things you would like to see improved.


    Rick Negrin
    Lead Program Manager
    SQL Azure
    Friday, August 7, 2009 7:02 PM

All replies

  • Ensure it works well with Entity Framework!

    Saturday, August 8, 2009 7:00 PM
  • We are interested in your wish list for new features -- a usage scenario for the new feature would help us understand the context of your needs

    Before asking our wish list of NEW features, it would be interesting to see the actual features ... come back when the CTP will be available and maybe you will get some answers.
    Sunday, August 9, 2009 8:18 PM
  • I agree that before we can really give you feedback on new features that we need to know what features you already have.

    That said, here's the one feature I'd give a liver for.  If you don't already have it: allow me to use my existing data access layer that uses ADO.NET to access SQL Azure.  If this means writing a wrapper that uses SQL Data Services (or anything else) to access the REST APIs, please do that for me.

    Although this will not be the only thing to be addressed, it will allow me to migrate many of my existing applications that currently use a hosted/on premise SQL Server.  Otherwise I won't even try to migrate - I'll only use Windows Azure for new solutions.
    Thursday, August 13, 2009 10:26 PM
  • The CTP works with the Entity Framework.  I have successfully used it by simply changing the connection string to point to the SQL Azure db.

    Friday, August 14, 2009 3:22 PM
  • I'd like column-level encryption and, better yet, TDE.

    The way I read the documentation is that row-level and column-level encryption isn't supported. Is this due to the certificate storage issues that currently limit production use of the Riviera sample code at http://code.msdn.microsoft.com/riviera?

    [Riviera includes implementation of Security Token Service (STS) using Geneva Framework in Windows Azure. We would like to emphasize that this scenario is currently not supported (at the time of July 2009 CTP). This is primarily because of lack of certificate store support in Windows Azure at this time. So although the implementation works in Windows Azure, we advise not to do so for production environment untill such scenario can be supported on Windows Azure and product group provides guidance to do so.]

    What is the strategy for encrypting or obfuscating personally identifiable information for PCI, HIPAA, et al in v1?

    What's in store for encryption (esp. TDE) in later releases beyond this from First round of Questions and Answers

    Will SDS support Database Encryption (certificate and key management).  Any support for row level versioning?

    Database encryption? Not initially, but it’s on the list and as we have demonstrated – if there is sufficient customer demand, it will be one of the first things we add after v1. As far as row level versioning, this can mean a few different things. Do we support statement level snapshot transactions? Yes. Do we support Change Data Capture? It is still being evaluated.

    I have assumed that "Database Encryption" above was interpreted as TDE.

    Update 8/17/2009: The Windows Azure Platform Training Kit August 2009 CTP doesn't include column-level TSQL encryption/decryption commands in the T-SQL Supported (v1) or T-SQL Not Supported (v1) slides. Which is it?

    --rj 


    OakLeaf Blog
    Saturday, August 15, 2009 10:08 PM
  • I'm REAL new to sql azure but I thought you could use ADO.Net in ASP.Net Web applications.

    http://blogs.msdn.com/ssds/archive/2009/08/18/9874133.aspx

    Thursday, August 20, 2009 1:22 PM
  • Badly need text, ntext, image datatype support to enable moving current databases to SADB.

    --rj
    OakLeaf Blog
    Thursday, August 20, 2009 11:46 PM
  • Badly need text, ntext, image datatype support to enable moving current databases to SADB.

    --rj
    OakLeaf Blog

    Is changing the types to varchar/varbinary a viable option?
    Program Manager, SQL Azure
    Friday, August 21, 2009 9:23 AM
  • Stan,

    Changing datatypes to varchar(max) and varbinary(max) is an option, which I used to generate Northwind from a modified version of Instnwind.sql. However, this requires changing existing scripts, packages, etc., which is a bummer.

    --rj
    OakLeaf Blog
    Saturday, August 22, 2009 5:58 PM
  • rj,

    We are not supporting features marked for deprecation and all three types you mentioned are in this category. From BOL
    (http://msdn.microsoft.com/en-us/library/ms187993.aspx):

    ntext, text, and image data types will be removed in a future version of Microsoft SQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.

    Stan
    Program Manager, SQL Azure
    Saturday, August 22, 2009 9:58 PM
  • Stan,

    Missed that in BOL, so I retract my request for ntext, text and image data types in SADB. I have a lot of scripts from many years prior to the (max) data types, though, but not sure how many would be cloud candidates.

    --rj 


    OakLeaf Blog
    Saturday, August 22, 2009 10:30 PM
  • A wish - Change tracking - using SQL AZure as the fault tolerant "Data Hub".

    ALTER DATABASE AdventureWorks
    SET CHANGE_TRACKING = ON
    (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)

    Erik Ejlskov Jensen, MCTS: WM App, MCITP: SQL 2008 Dev - http://erikej.blogspot.com Please mark as answer, if this was it.
    Monday, August 24, 2009 11:18 AM
  • I think for a CTP its working really well so far.  There are a few typos in the getting started documentation but the service has been spot on for me so far.

    I’ve got my SQL 2005 database scripted out and imported into a test SQL Azure database today and got the data moved in too.

    I’m already running my Azure service from the dev environment connecting to the SQL Azure database and its working well.  Not sure on performance yet but will be testing that shortly
    Wednesday, August 26, 2009 6:59 PM
  • Is it possible to see SQL Azure server logins statistics, i.e. how many logins were made, connect timestamp of each login, duration, data bandwitdhe etc...
    Thursday, August 27, 2009 6:26 PM
  • Importing an existing database from MS SQL Server 2008 is unnecessarily cumbersome right now. I'm using the training kit exercises "Migrating Databases to SQL Azure Exercise 1: Moving an Existing Database to the Cloud" from MSDN to script my DB and move it over. Since my DB is totally compliant with SQL Azure it would be nice if I could just upload the database's .MDF file and have the SQL Azure system just handle it right. If the DB wasn't compliant, it could just spit out an error.

    My current use scenario, which I expect must be quite common, is that I am making some relatively significant changes to my database in my development environment and I have to repeat the tedious steps to upload the database each time a set of database changes is ready. I can't really wait for them all to be ready before uploading them, so it would be nice to streamline that process.

    Tighter integration with Microsoft SQL Server Management Studio would also be nice. I would love to be able to use some of its visual tools, like building database diagrams directly into the cloud.

    Having said that, I think SQL Azure is a great product and seems to be getting better all the time! Thanks!
    Sunday, August 30, 2009 5:11 AM
  • I have a bunch of requests related to T-SQL and data management.  But even before that I believe SQL Azure needs better security, especially regarding the way it currently manages connections on TDS/port 1433.

    I started a whole thread on this:

      Suggestion: improve security by better managing failed TDS connections on port 1433
      http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/94acaffc-f0cb-4160-8a01-aa9f3657560f

    It includes two features requests - an "IP White List" and a temporary "User lockout" after failed login attempts.  Details are in the thread above.
    Sunday, August 30, 2009 10:36 PM
  • Hi, try put a script sample here http://www.sqlazureverifier.com/ and see what lines that will not be supported. BETA version of the site!
    Monday, August 31, 2009 2:56 PM
  • SQL Server Profiler is not supported today - I believe the justification is that it requires server level permissions and/or trace flags.

    However, SQL Profiler is a massively important tool in a SQL dev's armoury and there needs to be something that provides us the same capabilities. How can we debug perf problems without Profiler?

    One clear use case for Profiler is that the middle tier devs that I work with use Profiler to see what SQL their ORMs are producing. Yes yes....you can run queries locally against Express - I know that - but frankly that's almost becoming a cliche and a byword for the inabilities of SQL Azure. I can't help feeling that if you want people to take this platform seriously then "Just do some of the stuff against SQL Express" isn't going to cut the mustard I'm afraid. Hopefully that critcism is taken constructively, not disparigingly!

    So, please give us Profiler - or "Profiler Lite" at least.

    -Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Monday, August 31, 2009 9:30 PM
  • One clear use case for Profiler is that the middle tier devs that I work with use Profiler to see what SQL their ORMs are producing. Yes yes....you can run queries locally against Express - I know that - but frankly that's almost becoming a cliche and a byword for the inabilities of SQL Azure. I can't help feeling that if you want people to take this platform seriously then "Just do some of the stuff against SQL Express"
    I don't see the absence of a profiler as a show stopper even though the SQL Server profiler is open on my desktop most of the day. I have to question your development workflow Jamie.

    "Seeing what SQL an ORM generates". Definitely something that should be done on a developer's machine before deployment to Azure.

    You need to think of Azure as a production environment. I spent many years looking after a large SQL Server 24/7 production system and I doubt that we ran the sql profiler more than once a year against production in fear of hurting performance. SQL Perfmon stats are a different issue and I hope the SQL Azure team has a plan to log these figures out somewhere.

    There is one profiling situation that concerns me with SQL Azure. In the case of strange data distribution that creates perf problems in production and cannot be replicated with test data, we need the option to snapshot Azure DBs to Azure blob storage for later download to a development test area outside the Azure cloud. 
    Wednesday, September 2, 2009 4:43 PM
  • Fair point about the ORM dev .. I was kinda scratching around looking for more justification when I wrote that. However I still believe Profiler is vital because people will want to evaluate SQL Azure by testing round trip times versus what they might get with a hosted, single-tenant solution and for that Profiler would be very handy.
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Wednesday, September 2, 2009 9:00 PM
  • We hear the feedback.  We are working on updating SSMS to work seamlessly with SQL Azure. We are also updating the Generate Script Wizard in SSMS to spit out the right scripts that won't require any tweaking. It will also be a way to ensure your database will work with SQL Azure (the wizard will give you errors if you use any unsupported features).  We should have this done by PDC in November when we go live.  Even further in the future we will support the new deployment technologies being developed for SQL Server that will make deploying new DBs and updates to existing DBs even easier.

    Rick Negrin
    Lead Program Manager
    SQL Azure
    Friday, September 4, 2009 5:01 PM
  • I've got some pricing feedback for you.  From my perspective in terms of the cloud app we were hoping to create the pricing model on SQL Azure is NOT cloud friendly.  I'm pretty confused about why SQL is not being billed in the same manner as the rest of the services.  Few complaints;

    1)  From a design perspective each of our users should have their own database but in order to make it econmonical we might have to buy the larger databases and consolidate multiple customer systems into one.  In a business application this is not the way to go at all....

    2)  We're a very database centric development company and in our latest apps we store everything in the database.  Again - becuase of your limits and the expense of your model it makes more sense from a business perspective to store files outside of our database when from an architecture standpoint it makes more sense to store them in the database.

    3)  Why should someone who has a 2GB databse have to pay 10X as much as someone with a 750 meg DB - makes no sense (even with the "extras" you get with the bigger version).

    I understand managing databases is much more complicated than storing files but if you're building a traditional "cloud" app that might have thousands of customers - each wtih optimally their own database the pricing is outragious for what ultimatly might not be very much data.

    It seems to me that we could go spend $5K on a database server and it would handle about 25-2gb databases with ease (would cost $2,500 a month with you).  I realize there are other cost factors like internet connection, management of the hardware, electicity, etc but AREN'T WE SUPPOSED TO BE BENEFITTING FROM ECONOMIES OF SCALE HERE?????

    Host it myself;
    $5K for the server
    $5K for management of the hardware, internet connection, etc

    Total cost $10,000 for the first year (less in the second even!)

    Hosted in Azure
    $2,500 X 12 = $30,000

    Multiply this by 100 for what we're hoping to accomplish with our hosted app....

    Am I missing something here?


    Saturday, September 5, 2009 8:53 PM
  • I've got some pricing feedback for you.  From my perspective in terms of the cloud app we were hoping to create the pricing model on SQL Azure is NOT cloud friendly.  I'm pretty confused about why SQL is not being billed in the same manner as the rest of the services.  Few complaints;

    1)  From a design perspective each of our users should have their own database but in order to make it econmonical we might have to buy the larger databases and consolidate multiple customer systems into one.  In a business application this is not the way to go at all....

    2)  We're a very database centric development company and in our latest apps we store everything in the database.  Again - becuase of your limits and the expense of your model it makes more sense from a business perspective to store files outside of our database when from an architecture standpoint it makes more sense to store them in the database.

    3)  Why should someone who has a 2GB databse have to pay 10X as much as someone with a 750 meg DB - makes no sense (even with the "extras" you get with the bigger version).

    I understand managing databases is much more complicated than storing files but if you're building a traditional "cloud" app that might have thousands of customers - each wtih optimally their own database the pricing is outragious for what ultimatly might not be very much data.

    It seems to me that we could go spend $5K on a database server and it would handle about 25-2gb databases with ease (would cost $2,500 a month with you).  I realize there are other cost factors like internet connection, management of the hardware, electicity, etc but AREN'T WE SUPPOSED TO BE BENEFITTING FROM ECONOMIES OF SCALE HERE?????

    Host it myself;
    $5K for the server
    $5K for management of the hardware, internet connection, etc

    Total cost $10,000 for the first year (less in the second even!)

    Hosted in Azure
    $2,500 X 12 = $30,000

    Multiply this by 100 for what we're hoping to accomplish with our hosted app....

    Am I missing something here?



    Rick,
    Why is it an issue to use one DB for multiple users? Yes, befitting from economies of scale is exactly what SQL Azure is about but, surely, by dedicating an entire instance to each user you are completely flying in the face of that anyway because you're going to have a whole instance per user - how is that an economy of scale? Even in a hosted solution having a database per user is still basically a logical seperation (still the same server instance & still the same physical machine) - why not make the logical seperation to simply be a table called [User] instead where everything else has a FK (transitive or not) back to [User]?

    Please don't think I'm being criticial - I'm just interested to know why using one DB per multiple users is not viable for you.

    Regards
    -Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Sunday, September 6, 2009 3:02 PM
  • There's a quite a few reasons to have a seperate instance for each customer;

    1)  The size limitations in place are a concern for even single customers in probably 25% of cases.  In business apps where lots of transactions take place space goes fast.  Having the hard 10 gig limit for even single customers will create some issues for us eventually.

    2)  The type of apps we build are not like facebook or something to that effect - they are serious biz apps, the seperate databases make the apps more secure and protect our clients data.  Imagine if a bug in our software made it select the wrong row of data in a situation where we mixed customer information.  Think of salesforce.com, or another hosted business app - I would be shocked if they didn't have a seperate database for each customer.

    3)  Limitations of SQL - we have client databases that reach over 1 million rows in a single table - SQL starts to choke in certain circumstances and CPU usage goes up exponentially when you do thins like select MAX, etc - I expect Azure to suffer from some of the same problems.

    Does that make sense Jamie?

    Rick


    Monday, September 7, 2009 12:57 AM
  • There's a quite a few reasons to have a seperate instance for each customer;

    1)  The size limitations in place are a concern for even single customers in probably 25% of cases.  In business apps where lots of transactions take place space goes fast.  Having the hard 10 gig limit for even single customers will create some issues for us eventually.

    2)  The type of apps we build are not like facebook or something to that effect - they are serious biz apps, the seperate databases make the apps more secure and protect our clients data.  Imagine if a bug in our software made it select the wrong row of data in a situation where we mixed customer information.  Think of salesforce.com, or another hosted business app - I would be shocked if they didn't have a seperate database for each customer.

    3)  Limitations of SQL - we have client databases that reach over 1 million rows in a single table - SQL starts to choke in certain circumstances and CPU usage goes up exponentially when you do thins like select MAX, etc - I expect Azure to suffer from some of the same problems.

    Does that make sense Jamie?

    Rick



    Rick,
    Yeah, it absolutely does. Seems like SQL Azure isn't a good fit at all, right? The 10GB size limit seems to be the biggest blocker.

    Regarding 2) I don't know too much about building such apps because I'm a BI/DW guy so its revealing for me to know that they would be built this way (i.e. dedicated DB per customer). To me it makes more sense to have a single DB, seperate the data logically, and put lots of effort into ensuring that security is locked down as tight as it can be but I guess that's just my naivety.

    Thanks for the insights.

    -Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Monday, September 7, 2009 6:31 AM
  • Desparately need the ability to copy databases.  A key part of a SaaS offering is the ability for customers to easily "clone" their database to perform testing, training, etc. without upsetting their live data.  It is also important in the initial provisioning of the application where you might offer the customer a range of pre-populated "template" databases to choose from.

    This facility needs to be quick and easy to program via an API.
    Tuesday, September 8, 2009 4:23 PM
  • 1)  The size limitations in place are a concern for even single customers in probably 25% of cases.  In business apps where lots of transactions take place space goes fast.  Having the hard 10 gig limit for even single customers will create some issues for us eventually.

    Patric McElroy of Microsoft wrote the following on another forum thread:

    One of the primary drivers for the DB size limits is customer feedback.  Customers are planning to initially and primarily move web and departmental applications to a software services model.  Over time they will move bigger and more varied types of apps but the above are expected to be a primary source for the initial apps to move. 

    2)  The type of apps we build are not like facebook or something to that effect - they are serious biz apps, the seperate databases make the apps more secure and protect our clients data.  Imagine if a bug in our software made it select the wrong row of data in a situation where we mixed customer information.  Think of salesforce.com, or another hosted business app - I would be shocked if they didn't have a seperate database for each customer.

    I think this is more of a marketing concern than a technical concern. As Jamie Thomson pointed out the databases as "still [on] the same server instance & still [on] the same physical machine." Even with separate databases per customer it would still be possible for a bug to point at the wrong database so you still need to check inside a database that the data is for the right customer. My reason for suggesting this is a marketing concern is that I would be shocked if the largest e-commerce sites had separate databases for each customer.

    3)  Limitations of SQL - we have client databases that reach over 1 million rows in a single table - SQL starts to choke in certain circumstances and CPU usage goes up exponentially when you do thins like select MAX, etc - I expect Azure to suffer from some of the same problems.

    I would have thought that select MAX would bheave reasonably against an indexed column - but would not be surprised by unreasonable performance were it done using a table scan against any data storage system, SQL Azure or otherwise.

    Tuesday, September 8, 2009 6:45 PM
    Answerer
  • RickatRITE, with regard to point 2 you might be surprised to hear that SalesForce.com do actually keep all customer data in a single database, but to do this they have pretty much had to re-invent partitioning of data and I personally think the whole advantage of something like Azure is to take this worry away from the developer, so I do support your original post and would like to see ways of making it easier to copy databases and backup / restore databases in and out of the environment.
    Wednesday, September 9, 2009 2:35 PM
  • Hi Rick,

    I'm curious about the way you calculated your monthly charges. Can you explain a little bit about how you came up with 2500/month?

    I'm not sure of what your limitations are (other than space - 10GB is not a lot depending on data, users, etc.) but I can't imagine that the 10GB will be a hard limit for very long.

    As far as pricing, I was thinking it was reasonable in that I factored in passing the 199/month + usage marked up at 40% = about 249 + usage per customer. There would be one db per customer installation.

    Maybe we're using two different approaches or looking at it differently...very interesting!

    Thanks in advance.
    Thursday, September 10, 2009 5:44 AM
  • Would it be possible to get the SUSER_NAME(), HOST_NAME() functions put back in? I use them extensively for automatically tagging/auditing. I just started working with this I'm sure there'll be more...

    Thanks.
    Friday, September 11, 2009 2:05 AM
  • My users would like to see support for Null dates be brought back.  

    The default minvalue 1/1/1753 causes confusion for them.
    Monday, September 21, 2009 1:03 PM
  • Upload and Download Database Backup via API.

    We are a ISV and needs to make a migration for our customers very easy.

    Christopher

    Wednesday, October 7, 2009 3:02 PM
  • It would be important to me to have some sort of way to ping the azure service or do an snmp inquiry on the azure service so that we can know as soon as possible whenever a link to azure is down.
    Thursday, October 8, 2009 5:15 PM
  • The online UI for creation of database is simple.... why can n't be there some more enhancement to do more.
    Some more menu or buttons to create table and set some contrains etc ....
    It looks to me backward compatibility issues are there , i can not connect with a Sql 2005 query anlyser...not tried 2000..need to try replication...

    Thursday, October 15, 2009 6:20 AM
  • FulltextSearch support?
    Friday, October 16, 2009 11:22 PM
  • WebClient for accessing SADb (see http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/04d5c210-5014-4de2-aaad-97cbfe89cd14 ) by Microsoft.

    Programming is a kind of art but not all programmers are artists.
    Sunday, October 18, 2009 10:28 AM
  • Spatial data types are a must have for me. I write apps for the oil industry and atm we're considering changing from desktop apps to web or cloud apps. Most of our apps include maps showing oil wells, pipelines, discoveries, etc and we currently make extensive use of the spatial data types (SqlGeometry) and spatial queries in SQL Server to determine what wells, etc lie in an area.

    We are really keen to move to a service like Azure because it would solve a number of problems in deployment, scalability, etc but without the spatial data types we can't. Are they planned for a future version of SQL Azure?
    Thursday, October 29, 2009 2:36 PM
  • Spatial data types are planned for a future version of SQL Azure.

    Rick Negrin
    SQL Azure
    Friday, October 30, 2009 6:38 PM
  • I would like to see SELECT INTO working. There is a lot of code out there in sprocs that use this feature, especially SELECT INTO #temp_table. If it is not possible for some reason, then it is absolutely necessary to have a compiler error for SELECT INTO. Right now you only get a runtime error.

    The same thing with CLUSTERED INDEX for regular (not temporary) tables, it is absolutely necessary to have a compiler error for creating tables without a CLUSTERED INDEX. Right now you can create a table without it, but cannot ever use it, which does not make any sense.

    Thanks.
    Vadim

    Tuesday, November 3, 2009 10:51 PM
  • I would like to see SELECT INTO working. There is a lot of code out there in sprocs that use this feature, especially SELECT INTO #temp_table. If it is not possible for some reason, then it is absolutely necessary to have a compiler error for SELECT INTO. Right now you only get a runtime error.

    The same thing with CLUSTERED INDEX for regular (not temporary) tables, it is absolutely necessary to have a compiler error for creating tables without a CLUSTERED INDEX. Right now you can create a table without it, but cannot ever use it, which does not make any sense.

    Thanks.
    Vadim


    Azurehappy,
    I too would like to see SELECT INTO working. The reason it does not is that SELECT ... INTO cannot create tables with indexes, nd SQL Azure requires that all tables have an index.
    Hence we need a new version of SELECT ... INTO. I have asked for it here:

    New version of SELECT INTO that supports indexes
    (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=490142)

    Plesae feel free to click through and vote/comment.

    -Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Wednesday, November 4, 2009 7:00 AM
  • I would like to see SELECT INTO working. There is a lot of code out there in sprocs that use this feature, especially SELECT INTO #temp_table. If it is not possible for some reason, then it is absolutely necessary to have a compiler error for SELECT INTO. Right now you only get a runtime error.

    The same thing with CLUSTERED INDEX for regular (not temporary) tables, it is absolutely necessary to have a compiler error for creating tables without a CLUSTERED INDEX. Right now you can create a table without it, but cannot ever use it, which does not make any sense.

    Thanks.
    Vadim


    Azurehappy,
    I too would like to see this. The reasonthat SELECT INTO is not supported is that it does not create tables with indexes and SQL Azure requires that all tables have an index.

    Hence what is needed is a new construct to replace SELECT INTO. I have requested that here:

    New version of SELECT INTO that supports indexes
    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=490142

    Please feel free to click through and vote.

    -Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Wednesday, November 4, 2009 7:04 AM
  • Jamie,

    It is not clear for me what you mean by new version. A new keyword? I do not think it is a good idea. It should work as is, I my opinion, to avoid problems converting sprocs. And if it does not create a clustered index automatically now, well... it should.

    Vadim
    Wednesday, November 4, 2009 4:36 PM
  • Jamie,

    It is not clear for me what you mean by new version. A new keyword? I do not think it is a good idea. It should work as is, I my opinion, to avoid problems converting sprocs. And if it does not create a clustered index automatically now, well... it should.

    Vadim

    Not a new keyword necassarily but actually a complete new construct. SELECT INTO is not standard SQL (i.e. not ANSI-SQL), whereas "CREATE TABLE AS blah blah blah" is  (if you click through on the previous link I provided one of the commenters, David Portas, explains this rather well).
    Unfortunately SELECT ... INTO will never be made to work on SQL Azure simply because all SQL Azure tables require a clustered index (so that they can be replicated) and SELECT INTO does not support the creation ofa clustered index when it creates a table. The other option (as you suggest) is to change how SELECT INTO works but they won't do that (a) because of backward compatibility reasons and (b) as I explained above there is an ANSI-SQL compliant way of doing what we want. I agree that it SHOULD work but, as I say, I dn't think it ever will due to bad decisions made in the past.

    Sorry, I'm really not trying to play devil's advocate, I'm just telling you what the SQL team won't tell you themselves. I'd encourage you to go to the link above and air your views there - the more people complain about this big gaping hole in the product then the more likely they are to do something about it.

    regards
    Jamie
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Wednesday, November 4, 2009 7:54 PM
  • Jamie,

    NO-NO, completely new construct will not solve CURRENT problems. What we need is SELECT INTO working without modification. Especially SELECT INTO #temp_table, which can be easily done because temporary tables do not require clustered index. In case of SELECT INTO <regularTable> SQL Azure should create A clustered index automatically if it is necessary.

    I am sorry, but at the link above I would vote NO, because it is not what I would like to see implemented.

    Vadim

    Thursday, November 5, 2009 9:12 PM
  • Jamie,

    NO-NO, completely new construct will not solve CURRENT problems. What we need is SELECT INTO working without modification. Especially SELECT INTO #temp_table, which can be easily done because temporary tables do not require clustered index. In case of SELECT INTO <regularTable> SQL Azure should create A clustered index automatically if it is necessary.

    I am sorry, but at the link above I would vote NO, because it is not what I would like to see implemented.

    Vadim


    Well, like I said above I'm sure they will never do that, but feel free to ask anyway!
    http://sqlblog.com/blogs/jamie_thomson/ | http://jamiethomson.spaces.live.com/ | @jamiet
    Friday, November 6, 2009 6:36 AM
  • I first heard about SQL Azure at one of the first SDRs in Oct 2008 in Redmond.  At the time you were playing with the ACE storage mode, or whatever it was.  It looked a lot like Azure Blob Storage.

    The majority of us said that we need a Cloud Based SQL Server Database that would support our current apps and tool sets.

    In the following SDR you said that you were moving away from ACE and going to have more of a traditional relational model in the cloud.

    Now I am playing with the public CTP.

    All I have to say is GREAT JOB!!!

    95% of all of the applications that I have written over the past 13 years can be easily ported into SQL Azure.  All of my code still works, even the code that uses 3rd party ORM data access frameworks.  One of the most amazing things is that my integration tests that run against a cloud database run almost as fast as the same tests hitting a local database.

    Once again, great job.

    On another note, I remember in the first SDR, one of the program managers said that there would be a pricing model for the startups, a pricing model for the average small business, and a pricing model for the exxon mobile's of the world.  I said to myself that I would beleive it when I see it.  So far, I think your pricing models are spot on (for my business case anyway).

    So, once again great job and thanks for all of the hard work.  I cant wait for the entire stack to go live.

    Cheers

    Saturday, November 14, 2009 6:40 AM
  • how about a AZURE-V that runs on server 2008? i mean like the hyper-v but for playing with our AZURE stuff and testing it a little 'off line' first.
    Sunday, July 18, 2010 7:36 PM
  • We're using change tracking with SQL Server 2008 to synchronize application domains across multiple servers and it works really well with on-premise installations. We're currently about to start working with Microsoft to move our application to Azure and the lack of change tracking (as of this writing), requires us to fallback to a per-table based trigger approach that reproduces the change tracking infrastructure.

    I don't know why SQL Azure supports change data capture (CDC) but not change tracking; with CDC being the more complex counterpart (and more heavy on data), the only reason I can come up with is it's an async feature.

    Thougts on this?


    Anders Borum / SphereWorks
    Tuesday, November 29, 2011 3:30 PM