Jeroen Mostert

My feedback

  1. 15 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
    An error occurred while saving the comment
    Jeroen Mostert commented  · 

    Alternatively, simply change/extend `DATEADD` to accept `BIGINT` input -- the reason `DATEDIFF_BIG` has to be separate is because the return type changes. Changing `DATEADD` to accept `BIGINT` would have no backwards compat issues, as it would simply make scenarios that now produce overflow produce a result instead.

    The "killer app" for this is calculations involving timestamps in milliseconds or nanoseconds format (like Unix timestamps) which now require clumsy circumlocutions to convert with full precision.

  2. 16 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  1 comment  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
    An error occurred while saving the comment
    Jeroen Mostert commented  · 

    Still present as of CU15. This is extra annoying when you're deploying databases through DACPACs, as those embed the collation used in the database (that is, there's no simple way to just deploy the database with the server default collation, unless you arrange for the database to be created first separately).

  3. 27 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 158

    <=-=Dec 4 2009 10:01PM=-=>

    I think this goes further than computed columns, as a filtered index can’t be used for something as simple as WHERE num % 2 = 0 (with no computed columns in sight). I really want to see filtered indexes become more useful.

    <=-=Dec 7 2009 10:29AM=-=>

    Greg,

    Thanks for your feedback. I agree we should allow filtered indexes on persisted computed columns, and should support more complex filter expressions, at some point in the future. We restricted the functionality for the first version but we’ll consider this for a future release. The documentation should be more precise about the restrictions on predicate expressions. I’ll follow up on that.

    Best regards,
    Eric

    <=-=Dec 8 2009 8:56PM=-=>

    I was AMAZED when I could not create a filtered index on computed column.

    But I as APPALLED and DUMBFOUNDED when I could not create a filtered indexes on…

    Jeroen Mostert supported this idea  · 
  4. 12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 100

    <=-=Dec 7 2007 10:41AM=-=>

    Yes, this would be great. You can call views and stored procs from another server or another database; you should be able to call table-valued functions also.

    I hope this is fixed in SQL Server 2008.

    <=-=Dec 21 2007 2:15PM=-=>

    Thanks for your feedback regarding remote table-valued function calls. We are currently investigating the effort needed to implement this functionality. Since we are wrapping up our efforts on the next release of SQL Server (2008) it is unlikley that a fix will be available by then.

    Regards,

    Joachim Hammer

    Program Manager
    SQL Server

    <=-=Feb 22 2008 6:31AM=-=>

    This is one of those “loose ends” that frustrates the SQL 2005 users. I hope that the MS SQL 2008 team(s) will take care…

    <=-=Jul 3 2008 11:46AM=-=>

    Hope this is fixed soon. Big issue for linking two sql servers.

    <=-=Sep 23 2008 8:12AM=-=>

    Oh, gods, yes…

    Jeroen Mostert supported this idea  · 
  5. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 4

    <=-=Jun 6 2008 10:29AM=-=>

    Thanks for identifying this. we will consider this fix in the next release

    <=-=Jun 20 2015 1:30PM=-=>

    In SQL Server 2012 there is still Sort operator used when bulk loading into a table (empty) with Identity property, although data file is sorted and BULK INSERT is executed with ORDER hint.
    This issue was opened in 2008 and it’s still active, could you please fix it finally??
    It was really problematic back in the days when there was no workaround known as the one proposed in this issue, but do we really need to apply workarounds?
    This sort operator is not needed, that’s for sure.

    <=-=Sep 26 2017 7:15PM=-=>

    Still present in SQL Server 2017. This really should be addressed.

    Jeroen Mostert supported this idea  · 
  6. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
  7. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
  8. 23 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  8 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
    An error occurred while saving the comment
    Jeroen Mostert commented  · 

    There is a workaround, of sorts: if a query is wrapped in an `EXEC (...)`, metadata will be returned. Of course this only works if you can change the query.

  9. 12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  1 comment  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
  10. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert shared this idea  · 
  11. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert shared this idea  · 
  12. 19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Jeroen Mostert supported this idea  · 
  13. 30 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 47

    <=-=Jul 3 2014 10:03AM=-=>

    This would definitely be a good build. I walked through an initial investigation of clustered columnstore on one of our data sets, and the number of reads was reduced by about 80% for some queries in the workload once I started paying careful attention to segments and loading data in a single-threaded manner to optimize segment elimination. However, this results in slower loading of data, and it would be great to be able to create columnstore indexes in order for segment elimination.

    Having an optional ORDER BY clause for the columnstore initial creation, removing the need to first create a clustered index in order to control order and allowing parallelism without breaking order, would be particularly powerful.

    <=-=Jul 3 2014 10:30AM=-=>

    Neugebauer: thanks. you identified the issue correctly. This is something we are actively looking. One question
    (1) once the index is build, the…

    Jeroen Mostert supported this idea  · 
  14. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Jeroen Mostert commented  · 

    Fixed in 2016 SP1 CU8 and 2017 CU6, per https://support.microsoft.com/en-us/help/4089324 .

Feedback and Knowledge Base