/ / Da Linq a SQL (designer) non capisce la stored procedure - linq-to-sql, .net-3.5, stored-procedures

Linq to SQL (designer) non capisce la stored procedure - linq-to-sql, .net-3.5, stored-procedures

Perché il progettista Linq to SQL non può comprendere la seguente stored procedure e importarla correttamente?

CREATE PROCEDURE dbo.MartinTest
@parameter1 INTEGER

AS
SET NOCOUNT ON

SELECT C1, C2, C3
INTO #myTempTable
FROM MyTable

SELECT C1, C2, C3
FROM MyOtherTable INNER JOIN #myTempTable ON ....

RETURN

Quando utilizzo il designer per importare questa stored procedure, imposta il tipo restituito come "none", anche se l'SP restituisce chiaramente una o più righe di dati.

Considerando che, se rimuovo la prima istruzione select e invece semplicemente restituisco il contenuto della tabella originale ...

CREATE PROCEDURE dbo.MartinTest
@parameter1 INTEGER

AS
SET NOCOUNT ON

SELECT C1, C2, C3
FROM MyTable

RETURN

... il designer funziona correttamente e determina il tipo di reso corretto.

BTW: So che posso codificare manualmente la chiamata alla stored procedure, quindi non sto cercando un work-around, sono più interessato a sapere se si tratta di un bug nel designer per Linq a SQL o se si tratta di qualcos'altro. Sto usando VS2008 SP1.

Grazie.

risposte:

4 per risposta № 1

Questo non è tecnicamente un problema con il LinqProgettazione SQL, si tratta di un problema con SQL Server. La progettazione da Linq a SQL utilizza SET FMTONLY ON per ottenere le informazioni sul set di risultati di una stored procedure. Sfortunatamente, questo metodo non funziona quando la stored procedure ha una tabella temporanea.

C'è un piccolo avanti e indietro su questo nei primi commenti di Il blog di ScottGu.


1 per risposta № 2

Potresti manualmente SET FMTONLY OFF all'inizio della stored procedure. Probabilmente commentalo per un uso normale e commentalo solo quando generi le tue classi LINQ.