Maurice Pelchat

My feedback

  1. 208 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  20 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    I do use CROSS APPLY, and I do it extensively.
    For this example this is as simple as this.
    Computed columns through CROSS APPLY can be reused in subsequent CROSS APPLY to produce other computed columns and so on. Lot of fun!
    Select A, B, E, F
    From someTab
    CROSS APPLY (Select E=C-A) as E
    CROSS APPLY (Select F=E*2+C) as F

  2. 289 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Upvotes: 127

    <=-=Jun 23 2015 8:37AM=-=>

    I’m the first to post a useful comment. This must make me special.

    Seriously though, this would be an excellent solution to having to create a new “scratchdb” to hold my interim ETL data. This would be a major plus in simplifying design of a high performance app.

    <=-=Jul 3 2015 5:04AM=-=>

    In 2014, memory optimized tables, and delayed durability can be used help mitigate these Issues. However neither of this are always completely viable solutions. Brent’s proposed solution is likely the simplest way to achieve this with the least amount of unwanted impact. It is important to note that other platforms implement similar functionality as well. Notably Oracle.

    <=-=Nov 29 2016 3:58PM=-=>

    There are so many good things about this suggestion. I am amazed that SQL does not have the capability to turn off logging for certain tables that you define as no…

    Maurice Pelchat supported this idea  · 
  3. 453 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    14 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Maurice Pelchat supported this idea  · 
  4. 1,001 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    529 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    Did you envision the possibility to rewrite it from scratch? Maybe there is some opensource code that could help? For me, I would accept to redo my diagrams from scratch.

    Another alternative could be to store the info in XML instead of the binary format used. Maybe it would be easier to find out what info is missing when trying to open the last diagram saved.

    Another suggestion to dig into the problem would be to try with a very simple diagram, just two small tables, to find out what corrupts the data. Smaller datasets are easier to debug.

    Home some of my suggestions may help.

    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    I was so happy to have them back, but an "only once use" for a diagram, is not a great feature ;)

    Maurice Pelchat supported this idea  · 
    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    They only reason this tool was disliked by some people was because of a very simple UX problem. People hate to click inadvertently on it while trying to open the database's table tree. The best solution would just have been to move it somewhere else in the list, not to remove it!

    It is still useful to many people... Bring it back, and put it after "Security" folder.

    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    They only reason this tool was disliked was because of a simple UX problem. People hate to click inadvertently on it while trying to open the database's table tree. The best solution would just have been to move it somewhere else in the list, not to remove it!

    It is still useful to many people... Bring it back, and put it after "Security" folder.

  5. 819 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    303 comments  ·  SQL Server  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    Wonder why Microsoft didn't even try to justify the deprecation yet!

    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    I agree with most comments, when you write procedural, imperative code you need a debugger. What is the solution we have now, guesswork, print trace, writing trace data to table? Sorry, this is even not possible with function (scalar or table).

    Really a bad idea.

    BTW Visual studio is a resource hog, so I don't want to add it to my computer for that kind of work.

    Maurice Pelchat supported this idea  · 
  6. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Maurice Pelchat supported this idea  · 
    Maurice Pelchat shared this idea  · 
  7. 9 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Maurice Pelchat supported this idea  · 
  8. 524 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Upvotes: 72

    <=-=Mar 10 2016 11:26AM=-=>

    It’s a shame that this was submitted as just a “suggestion”. It should actually be listed as a “bug” because there’s only a comparatively small set of use cases where enumeration of the result set of elements is not important.

    <=-=Mar 11 2016 12:47PM=-=>

    I agree that an order column is required; one example use case is where two lists are passed in, and ordinal positions in one list correspond to positions in the other.

    <=-=Mar 11 2016 3:12PM=-=>

    Please see the related suggestion: STRING_SPLIT needs “RemoveEmptyEntries” option, like String.Split in .NET ( https://connect.microsoft.com/SQLServer/feedback/details/2462002/ ).

    <=-=Mar 12 2016 12:02PM=-=>

    This kind of function is primarily needed for de-serializing previously serialized arrays of values of any type format-able as text.
    I therefore recommend to have the result set of this function work excellent with this use-case.

    With de-serialized arrays there is a need to…

    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    Adding a column returning ordinal order of elements is a must. It has many useful applications. Since it is a table result, it would not create problems for existing code, which cannot actually refer to this column. Many other related items can be added manually by the developer, but since we can't get the order reliably, SQL Server should do it.

    With an empty delimiter string, splitting at the character level would be very useful also.

    Maurice Pelchat supported this idea  · 
  9. 8 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    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 →
    Maurice Pelchat shared this idea  · 
  10. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  1 comment  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Maurice Pelchat commented  · 

    I dislike the idea of having to clutter the database of objects that exists only to make code reusable for a single object. It reduces the need of deferred name resolution on views and functions. Obviously internal reusable code module would, by definition, only exists into the scope of the main module.

    Maurice Pelchat shared this idea  · 
  11. 4 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 1

    <=-=Dec 15 2014 8:59AM=-=>

    Hello,
    After carefully evaluating all of the suggestion items in our pipeline, we are closing items that we will not implement in the near future due to current higher priority items. We will re-evaluate the closed suggestions again in the future based on the product roadmap.
    Thanks again for providing the product suggestion and continued support for our product.

    Jos de Bruijn – SQL Server PM

    Maurice Pelchat supported this idea  · 
  12. 6 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Maurice Pelchat supported this idea  · 
  13. 3 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Upvotes: 4

    <=-=Jul 21 2009 7:55AM=-=>

    Hi,

    Thankyou for this suggestion. Makes good sense. (Of course, declaring @coldat to be typeof foo.col1 would still allow us to call get_foo with any argument of that type. That’s to say, it does not tie get_foo to work only with the particular column foo.col1)

    (It’s also worth considering that typeof could apply, not just to a single column, but a set of columns)

    Amazing really that such a simple idea (which is time-saving, and avoids spontaneous breakage down-the-line) was not included into the SQL language from the outset.

    Anyhow, I’ll add it into the TODO list.

    Thanks,

    Jim Hogg

    <=-=Aug 18 2009 11:02AM=-=>

    The was a great feature that Informix had almost 10 years ago. You never had to look up the exact column var type from the table. We get bugs all the time from column sizes being increased, but the sproc…

    Maurice Pelchat supported this idea  · 
  14. 2 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    Upvotes: 26

    <=-=Aug 27 2009 6:17AM=-=>

    If this is indeed a bug and a fix is already planned for it in a release/SP/hotfix, please let me know the details of the release. Thanks.

    <=-=Sep 1 2009 4:37PM=-=>

    Hi,
    Thanks for your request. We are aware of the restrictions on UDFs with linked server / distributed query. We are looking at relaxing this in a future version of SQL Server.


    Umachandar, SQL Programmability Team

    <=-=Apr 4 2013 1:00PM=-=>

    FOUR YEARS AND STILLCONSIDERING IT”…! STUNNING!

    ANY UPDATE, PLEASE, MICROSOFT?

    Maurice Pelchat supported this idea  · 

Feedback and Knowledge Base