¿Cómo puede ver el sql que causa un error en SubmitChanges en LINQ to SQL?

Question

Tengo un poco de LINQ to SQL que a veces lanza un

"No se puede insertar una fila de clave duplicada en el objeto 'dbo.Table' con índice único 'IX_Indexname'.The instrucción se ha terminado."

¿Hay alguna manera de activar el registro o al menos depurar en el contexto de datos para ver qué sql se está ejecutando en el momento en que se produce el error?

Actualización: debería haber mencionado que sé sobre el método GetChangeSet(), me preguntaba si hay una propiedad en la DataContext que muestra la última SQL que se ejecutó, o una propiedad en la excepción de SQL que muestra el SQL .

Lo curioso de este error es que en los conjuntos de cambios, solo hay una actualización &, el único campo que cambia es un campo de fecha y hora que no está en el índice que causa el error.

Answer 1

Una forma sencilla de hacer esto es utilizar el DataContext.Log propiedad:

using (MyDataContext ctx = new MyDataContext()) 
{ 
    StringWriter sw = new StringWriter(); 
    ctx.Log = sw; 

    // execute some LINQ to SQL operations... 

    string sql = sw.ToString(); 
    // put a breakpoint here, log it to a file, etc... 
} 

Answer 2

Cuando me encuentro con este tipo de problemas, he estado usando el generador de perfiles SQL. Básicamente encender el generador de perfiles, poner un punto de interrupción en el guardar/actualizar, borrar el generador de perfiles y luego ejecutar solo esa declaración. A partir de ahí tengo todo el SQL que se ejecutó y puedo ver lo que se generó. [En general, he estado haciendo esto a través de DataServices, por lo que .SaveChanges() es una ubicación muy conveniente para poner el punto de interrupción]

Answer 3

Puede usar el generador de perfiles SQL para ver el SQL mientras golpea el servidor SQL.

Si quieres ver lo que realmente está en el cambio fija es necesario utilizar:

context.GetChangedSet(); 

MSDN - http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.getchangeset.aspx

A continuación, puede ver cada sentencia SQL antes de ser enviada al servidor.

Su último punto de llamada es utilizar la capacidad de VS 2008 para depurar a través de .NET Framework.

Answer 4

escribir una prueba para aislar la pieza o piezas de código que causa todos los problemas. Establecer DataContext.Log = Console.Out. Ejecute la prueba con un testrunner (NUnit, MSTest, etc.). Los testrunners normalmente muestran todo lo impreso en Console.Out junto con los resultados de la prueba.

Answer 5

utilice el Analizador de SQL. Es tu amigo y se envía con SQL. puede ver cualquier instrucción SQL que se esté ejecutando, con control total sobre el filtrado.

Answer 6

Tengo que estar de acuerdo con Bradley Grainger usando la propiedad DataContext.Log es la mejor manera de ver el sql ejecutado.