Stored procedure returns int instead of result set

Question

I have a stored procedure that contains dynamic select. Something like this:

ALTER PROCEDURE [dbo].[usp_GetTestRecords] 
    --@p1 int = 0, 
    --@p2 int =          


        

Answer 1

You may have luck opening up the model browser, then going to Function Imports, double clicking the stored procedure in question and then manually clicking "Get Column Information" and then clicking "Create New Complex Type". This usually sorts out the problem.

Answer 2

I had the same problem, I changed the name of return fields by 'AS' keyword and addressed my problem. One reason for this problem is naming column names with SQL Server reserved keywords.

The example is fallows:

ALTER PROCEDURE [dbo].[usp_GetProducts]

AS
BEGIN

 SET NOCOUNT ON;

 SELECT 
      , p.Id
      , p.Title
      , p.Description AS 'Description'

    FROM dbo.Products AS p
END

Answer 3

Just change to

ALTER PROCEDURE [dbo].[usp_GetTestRecords] 
    --@p1 int = 0, 
    --@p2 int = 0
    @groupId nvarchar(10) = 0
AS
BEGIN
    SET NOCOUNT ON;


    SELECT * FROM CUSTOMERS WHERE Id =  @groupId

END

Answer 4

See Ladislav Mrnka's answer in this Stack Overflow post https://stackoverflow.com/a/7131344/4318324

I had the same basic problem.

Adding

SET FMTONLY OFF

To a procedure you are trying to import during the import will address this problem. It's a good practice to remove the line afterwards unless the purpose of the database is solely to provide schema for EF (Entity Framework).

The main reason for caution is that EF uses this setting to prevent data mutations when trying to obtain metadata.

If you refresh your entity model from a database any procedures with this line in them can potentially update the data in that database just by trying to obtain the schema.

I wanted to add a further note on this so it's not needed to fully scan through the other link.

if you want to try to use FMTONLY here are a couple things to keep in mind.

when FMTONLY is on:
  1) only the schema is returned (no) rows.
     similar to adding a blanket false statement to your where clause (ie "where 1=0")
  2) flow control statements are ignored

Example

set fmtonly on

if 1=1
begin
    select 1 a
end
else
begin
    select 1 a,2 b
end

while 1=1
select 1 c

The above returns NO rows whatsoever and the metadata for each of the three queries

For this reason some people suggest toggling it off in a way that takes advantage of it's non-observance of flow control

if 1=0
begin
    set fmtonly off
end

In fact you could use this to introduce logic that tracks this

set fmtonly off
declare @g varchar(30)
set @g = 'fmtonly was set to off'

if 1=0
begin
    set fmtonly off
    set @g = 'fmtonly was set to on' 
end

select @g

Think VERY CAREFULLY before trying to use this feature as it is both deprecated and potentially makes sql extremely hard to follow

the MAIN concepts that need to be understood are the following

1. EF turns FMTONLY on to prevent MUTATING data from executing stored procedures
   when it executes them during a model update.
   (from which it follows)

2. setting FMTONLY off in any procedure that EF will attempt to do a schema scan
   (potentially ANY and EACHONE) introduces the potential to mutate database
   data whenever *anyone* attempts to update their database model.

Answer 5

I know this is an old thread but in case someone has the same problems I'll tell my woes.

As a help to find the issue, run sql profiler when you add your stored proc. Then you can see what entity framework is passing as parameters to generate your resultset. I imagine nearly always it will pass null parameter values. If you are generating sql on the fly by concatenating string values and parameter values and some are null then the sql will break and you wont get a return set.

I haven't needed to generate temp tables or anything just an exec command.

Hope it helps

Answer 6

I have pondered this a bit and I think I have a better/simpler answer

If you have a complex stored that gives entity framework some difficultly (for current versions of Entity Framework that are using the FMTONLY tag to aquire schema)

consider doing the folowing at the beginning of your stored procedure.

--where [columnlist] matches the schema you want EF to pick up for your stored procedure

if 1=0
begin
    select 
       [columnlist]
    from [table list and joins]
    where 1=0
end

if you are okay loading your result set into a table variable you can do the following to help keep your schema in sync

declare @tablevar as table
(
    blah int
    ,moreblah varchar(20)
)

if 1=0
begin
    select * from @tablevar
end

...
-- load data into @tablevar
select * from @tablevar