Skip to content

Settings and activity

1 result found

  1. 6 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

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Anonymous commented  · 

    Linus, I understand you here. For what it's worth, I use tons of scalar UDFs in my TSQL. Interestingly, when I use a specific format for my UDF calls, the same non-scalar warning will be generated, for example:

    DECLARE @BrowserId INT = (SELECT [dbo].[Get.Browser.Id.By.Name](@BrowserName));

    In this case, an ID is being returned for a specific browser residing in a table for which a unique constraint is placed on the browser name so only one result is possible, but this call format will produce the non-scalar warning you mention. Using another format, which I always use whenever possible does not produce the warning, although the output result is the same:

    DECLARE @BrowserId INT = [dbo].[Get.Browser.Id.By.Name](@BrowserName);

    I'm not suggesting that you wrap all your calls in UDFs. I want to share my experience with the same issue and how my incidental habit of turning TSQL into my own brand of language via encapsulating common calls for my procedures into application-specific functions somehow circumvents this issue with a slight difference in syntax. I don't pretend to know exactly why the syntax difference works, but I want to put it out here in case it helps you or anyone else.

    Anonymous supported this idea  ·