Maurice Pelchat

My feedback

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

    We’ll send you updates on this idea

    10 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    planned  ·  Matteo Taveggia responded

    Thanks for the suggestion. We’ll take a look at it and prioritize accordingly.

    Thanks,
    -Matteo

    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  · 
  2. 234 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    78 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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  · 
  3. 65 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    39 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Maurice Pelchat supported this idea  · 
    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.

  4. 91 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    53 comments  ·  SQL Server » Other  ·  Flag idea as inappropriate…  ·  Admin →
    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.

    Maurice Pelchat supported this idea  · 
    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. 65 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    12 comments  ·  SQL Server » Other  ·  Flag idea as inappropriate…  ·  Admin →
    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. 193 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 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…

    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. 7 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 →
    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. 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: 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. 5 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. 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 » 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