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