Как вы можете увидеть sql, который вызывает ошибку при подаче изменений в LINQ to SQL?

#c# #.net #sql #linq #linq-to-sql

Вопрос:

У меня есть некоторые ссылки на SQL, которые иногда вызывают

«Не удается вставить дублирующуюся строку ключа в dbo объекта.Таблица» с уникальным индексом «IX_Indexname».Заявление было прекращено».

Есть ли какой-нибудь способ включить ведение журнала или, по крайней мере, отладку в datacontext, чтобы увидеть, какой sql выполняется в момент возникновения ошибки?

Обновление: Я должен был упомянуть, что знаю об этом GetChangeSet() методе, мне было интересно, есть ли свойство в DataContext, которое показывает последний выполненный SQL, или свойство в исключении sql, которое показывает SQL.

Странная вещь в этой ошибке заключается в том, что в наборах изменений есть только одно обновление, и единственное изменяющееся поле-это поле даты и времени, которого нет в индексе, вызвавшем ошибку.

Ответ №1:

Простой способ сделать это-использовать свойство DataContext.Log:

 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...
}   
 

Комментарии:

1. Использование SQL profiler было бы предпочтительным решением, так как вам вообще не пришлось бы изменять свой код.

Ответ №2:

Когда я сталкивался с проблемами такого типа, я использовал профилировщик SQL. В основном включение профилировщика, установка точки останова для сохранения/обновления, очистка профилировщика, а затем запуск только этого оператора. Оттуда у меня есть весь SQL, который был выполнен, и я могу видеть, что было сгенерировано. [Я в основном делал это через службы данных, поэтому .SaveChanges () — очень удобное место для размещения точки останова]

Ответ №3:

Напишите тест, чтобы изолировать фрагмент или фрагменты кода, вызывающие все проблемы. Установите DataContext.Log = Console.Out. Запустите тест с помощью testrunner (NUnit, MSTest и т. Д.). Тестеры обычно отображают все, что печатается на консоли.Вышел вместе с результатами теста.

Ответ №4:

Вы можете использовать профилировщик SQL для просмотра SQL по мере его попадания на SQL-сервер.

Если вы хотите увидеть, что на самом деле находится в наборах изменений, которые вам нужно использовать:

 context.GetChangedSet();
 

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

Затем вы можете просмотреть каждую инструкцию SQL перед ее отправкой на сервер.

Ваш последний пункт вызова-использовать возможность VS 2008 для отладки через .СЕТЕВАЯ структура.

Ответ №5:

используйте профилировщик SQL. Это ваш друг и поставляется с SQL. вы можете просматривать любые выполняемые инструкции SQL с полным контролем над фильтрацией.

Ответ №6:

Я должен согласиться с Брэдли Грейнджером, что использование свойства DataContext.Log-лучший способ увидеть выполняемый sql.