EF não pode inferir o esquema de retorno do Stored Procedure selecionando de uma tabela #temp

Suponha o seguinte:

CREATE PROCEDURE [MySPROC] AS BEGIN CREATE TABLE #tempSubset( [MyPrimaryKey] [bigint] NOT NULL, [OtherColumn] [int] NOT NULL) INSERT INTO #tempSubset (MyPrimaryKey, OtherColumn) SELECT SomePrimaryKey, SomeColumn FROM SomeHugeTable WHERE LimitingCondition = true SELECT MyPrimaryKey, OtherColumn FROM #tempSubset WHERE SomeExpensiveCondition = true END 

Quando eu gero uma function import ou mapeio um tipo de retorno, o EF não gera um tipo complexo ou me diz:

O procedimento armazenado selecionado ou function não retorna nenhuma coluna

Como superar isso?

Outras respostas sugerem usar variables ​​de tabela (não fazer isso por motivos de desempenho) falsificando o esquema de retorno e comentando o procedimento armazenado real , outras sugerem fazer semelhante com visualizações … mas deve haver uma maneira de fazer isso sem ter que adicionar sobrecarga desnecessária ou exigindo que eu quebre um procedimento armazenado para atualizar o modelo?

 CREATE PROCEDURE [MySPROC] AS BEGIN --supplying a data contract IF 1 = 2 BEGIN SELECT cast(null as bigint) as MyPrimaryKey, cast(null as int) as OtherColumn WHERE 1 = 2 END CREATE TABLE #tempSubset( [MyPrimaryKey] [bigint] NOT NULL, [OtherColumn] [int] NOT NULL) INSERT INTO #tempSubset (MyPrimaryKey, OtherColumn) SELECT SomePrimaryKey, SomeColumn FROM SomeHugeTable WHERE LimitingCondition = true SELECT MyPrimaryKey, OtherColumn FROM #tempSubset WHERE SomeExpensiveCondition = true END 

Fornecer um contrato de dados falsos para o conjunto de resultados é a maneira mais fácil, limpa e rápida de resolver o problema. Esse mesmo problema existe nos controles de fonte de dados no SSIS também. O .NET lerá o conjunto de resultados da seção inacessível de “contrato” da consulta e fornecerá os metadados para o tipo complexo. Sem impacto no desempenho e sem necessidade de comentar o SQL que faz o trabalho real.

Adicionando isso ao topo da definição do procedimento armazenado:

 SET FMTONLY OFF 

permitiu que o modelo inferisse o esquema da tabela temporária sem problema. Como bônus, não requer manutenção adicional para um contrato.

Exemplo:

 SET FMTONLY OFF CREATE TABLE #tempTable ( ... ) ... SELECT * FROM #tempTable 

Solução 1 Use uma variável de tabela em vez de uma tabela temporária.

Solução 2 Use o Set FMTONLY desligado; Comando SQL no procedimento e você obterá as informações da coluna para criar um novo tipo complexo.

Solução 3 Esta não é uma boa maneira, mas é uma maneira muito fácil. Basta adicionar uma instrução select com dados fictícios e ela não será executada porque 1 = 0.

você pode verificar detalhes neste link