Solución:
EF no admite la importación de procedimientos almacenados que compilan un conjunto de resultados a partir de:
- Consultas dinámicas
- Mesas temporales
El motivo es que para importar el trámite EF debe ejecutarlo. Tal operación puede ser peligrosa porque puede desencadenar algunos cambios en la base de datos. Por eso, EF usa un comando SQL especial antes de ejecutar el procedimiento almacenado:
SET FMTONLY ON
Al ejecutar este comando, el procedimiento almacenado devolverá solo “metadatos” sobre las columnas en su conjunto de resultados y no ejecutará su lógica. Pero debido a que la lógica no se ejecutó, no hay una tabla temporal (o una consulta dinámica construida), por lo que los metadatos no contienen nada.
Tiene dos opciones (excepto la que requiere reescribir su procedimiento almacenado para no usar estas características):
- Defina el tipo complejo devuelto manualmente (supongo que debería funcionar)
- Use un truco y solo para agregar el procedimiento almacenado, coloque al principio
SET FMTONLY OFF. Esto permitirá que el resto del código de su SP se ejecute de forma normal. ¡Solo asegúrese de que su SP no modifique ningún dato porque estas modificaciones se ejecutarán durante la importación! Después de una importación exitosa, elimine ese truco.
Agregar este bloque de código no lógico resolvió el problema. Aunque nunca golpeará
IF 1=0 BEGIN
SET FMTONLY OFF
END
¿Por qué a mi conjunto de datos escrito no le gustan las tablas temporales?
http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataset/thread/fe76d511-64a8-436d-9c16-6d09ecf436ea/
O puede crear un tipo de tabla definido por el usuario y devolverlo.
CREATE TYPE T1 AS TABLE
( ID bigint NOT NULL
,Field1 varchar(max) COLLATE Latin1_General_CI_AI NOT NULL
,Field2 bit NOT NULL
,Field3 varchar(500) NOT NULL
);
GO
Luego en el procedimiento:
DECLARE @tempTable dbo.T1
INSERT @tempTable (ID, Field1, Field2, Field3)
SELECT .....
....
SELECT * FROM @tempTable
Ahora EF debería poder reconocer el tipo de columnas devueltas.