Отладка LINQ к SQL SubmitChanges ()

Опубликовал мой опыт с этим исключением в ответе на SO # 237415

Я недавно встретился с той же проблемой: то, что я сделал, было

Proce proces = unit.Proces.Single(u => u.ProcesTypeId == (from pt in context.ProcesTypes
                                                                         where pt.Name == "Fix-O"
                                                                         select pt).Single().ProcesTypeId &&
                                                                      u.UnitId == UnitId);

Вместо:

Proce proces = context.Proces.Single(u => u.ProcesTypeId == (from pt in context.ProcesTypes
                                                                     where pt.Name == "Fix-O"
                                                                     select pt).Single().ProcesTypeId &&
                                                                  u.UnitId == UnitId);

, Где контекст был, очевидно, объектом DataContext и "единицей" экземпляр объекта Единицы, Класса Данных из dbml файла.

Затем, я использовал объект "proce" установить свойство в экземпляре другого Объекта класса Данных. Вероятно, механизм LINQ не мог проверить, был ли свойство, я сходил с объекта "proce", позволен в команде INSERT, которая оказывалась перед необходимостью быть созданной LINQ для добавления другого Объекта класса Данных к базе данных.

Проверьте, что все столбцы "первичного ключа" в Вашем dbml на самом деле касаются первичных ключей на таблицах базы данных. У меня просто была ситуация, где разработчик решил поместить дополнительный столбец PK в dbml, который означал, что LINQ к SQL не мог найти обе стороны внешнего ключа при сохранении.

Я отправил подобный вопрос ранее сегодня здесь: Странное Исключение LINQ (Индекс за пределы) .

Это - различный вариант использования - где эта ошибка происходит во время SubmitChanges (), мой происходит во время простого запроса, но это - также Индекс из ошибки диапазона.

Перекрестная рассылка в этом вопросе в случае, если комбинация данных в вопросах помогает доброму самаритянину ответить также:)

Мы на самом деле прекратили использовать Linq для разработчика SQL для наших крупных проектов, и этой проблемой является одна из главных причин. Мы также изменяем много значений по умолчанию для имен, типов данных и отношений, и время от времени разработчик потерял бы те изменения. Я никогда не находил точную причину, и я не могу надежно воспроизвести ее.

, Что, наряду с другими ограничениями заставил нас отбрасывать разработчика и разрабатывать классы вручную. После того, как мы привыкли к шаблонам, это на самом деле легче, чем использование разработчика.

Hrm.

Взятие ВЗМАХА (Дикое Предположение Задницы), это смотрит на меня как LINQ - SQL пытается найти объект с идентификатором, который не существует, базирующийся так или иначе на создании класса JobMaster. Там внешние ключи связаны с той таблицей, таким образом, что LINQ к SQL попытался бы выбрать экземпляр класса, который не может существовать? Вы, кажется, устанавливаете ProjectID нового объекта к строке - у Вас действительно есть идентификатор, это - строка? При попытке установить его на новый проект, необходимо будет создать новый проект и получить его идентификатор.

Наконец, что делает UpdateJobMaster? Это могло делать что-то таким образом, что вышеупомянутое применялось бы?

VS 2008 имеет возможность отладки через платформу .NET ( http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net -framework-source-code.aspx )

Это, вероятно, ваша лучшая ставка, вы можете увидеть, что происходит и каковы все свойства в конкретный момент времени

Почему Вы делаете UpdateJobMaster на новом экземпляре? Разве это не должен быть InsertOnSubmit?

JobMaster newJobToCreate = new JobMaster();
newJobToCreate.JobID = 9999
newJobToCreate.ProjectID = "New Project";
this.InsertOnSubmit(newJobToCreate);
this.SubmitChanges();

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

, Который, конечно, только помогает, как только Вы заканчиваете исключения...

Это то, что я сделал

...
var builder = new StringBuilder();
try
{
    context.Log = new StringWriter(builder);
    context.MY_TABLE.InsertAllOnSubmit(someData);
    context.SubmitChanges();                
}
finally
{
    Log.InfoFormat("Some meaningful message here... ={0}", builder);
}

Ошибка, которую Вы отсылаете к вышеупомянутому, обычно вызывается ассоциации, указывающие в неправильном направлении . Это происходит очень легко при ручном добавлении ассоциаций к разработчику, так как стрелки ассоциации в разработчике L2S показывают назад когда по сравнению с инструментами моделирования данных.

было бы хорошо, если бы они выдали более описательное исключение, и возможно они будут в будущей версии. (Damien / Matt...?)

Можно ли создать частичный класс для DataContext и использовать ли Созданный или что имеет Вас частичный метод для установки журнала к console.out, обернутому в ОТЛАДКУ #if.. это поможет Вам видеть запросы, выполняемые при отладке любого экземпляра datacontext, который Вы используете.

я нашел это полезным при отладке LINQ к исключениям SQL..

partial void OnCreated()
{
#if DEBUG
      this.Log = Console.Out;
#endif
}

Мое первое действие отладки должно было бы посмотреть на сгенерированный SQL:

JobMaster newJobToCreate = new JobMaster();
newJobToCreate.JobID = 9999
newJobToCreate.ProjectID = "New Project";
this.UpdateJobMaster(newJobToCreate);
this.Log = Console.Out; // prints the SQL to the debug console
this.SubmitChanges();

второе должно было бы получить ChangeConflictException и взглянуть на детали отказа.

  catch (ChangeConflictException e)
  {
    Console.WriteLine("Optimistic concurrency error.");
    Console.WriteLine(e.Message);
    Console.ReadLine();
    foreach (ObjectChangeConflict occ in db.ChangeConflicts)
    {
      MetaTable metatable = db.Mapping.GetTable(occ.Object.GetType());
      Customer entityInConflict = (Customer)occ.Object;
      Console.WriteLine("Table name: {0}", metatable.TableName);
      Console.Write("Customer ID: ");
      Console.WriteLine(entityInConflict.CustomerID);
      foreach (MemberChangeConflict mcc in occ.MemberConflicts)
      {
        object currVal = mcc.CurrentValue;
        object origVal = mcc.OriginalValue;
        object databaseVal = mcc.DatabaseValue;
        MemberInfo mi = mcc.Member;
        Console.WriteLine("Member: {0}", mi.Name);
        Console.WriteLine("current value: {0}", currVal);
        Console.WriteLine("original value: {0}", origVal);
        Console.WriteLine("database value: {0}", databaseVal);
      }
    }
  }

Это почти наверняка не будет основной причиной для всех, но я столкнулся с этим точно таким же исключением в моем проекте - и обнаружил, что основной причиной было то, что исключение создавалось при создании класса сущностей. Как ни странно, истинное исключение «потеряно» и вместо этого проявляется как исключение ArgumentOutOfRange, возникающее на итераторе оператора Linq, который извлекает объект (ы).

Если вы получаете эту ошибку и ввели свои методы OnCreated или OnLoaded в свои POCO, попробуйте выполнить эти методы.

Я всегда находил полезным для знания точно, какие изменения отправляются DataContext в SubmitChanges () метод.

Я использую DataContext. GetChangeSet () метод, это возвращает экземпляр объекта ChangeSet, который содержит 3 IList's только для чтения объектов, которые были или добавлены, изменены или удалены.

Можно поместить точку останова незадолго до вызова метода SubmitChanges и добавить Часы (или Быстрые Часы) содержащий:

ctx.GetChangeSet();

Где ctx является текущим экземпляром Вашего DataContext, и затем Вы сможете отследить все изменения, которые будут эффективными на вызове SubmitChanges.

У меня была такая же ошибка, не связанная с речью.

У меня было отношение внешнего ключа к столбцу таблицы, который был не первичным ключом таблицы, а уникальным столбцом. Когда я изменил уникальный столбец на первичный ключ таблицы, проблема исчезла.

Надеюсь, это кому-нибудь поможет!