c# - несколько - linq select new



System.Data.Linq.ChangeConflictException: строка не найдена или изменена (12)

Вы получаете эту ошибку вполне возможно, потому что одно из ваших полей имеет что-то другое в дизайне Linq To SQL и в реальной базе данных.

В моем случае это было потому, что одно из полей было нулевым в базе данных и не было нулевым в дизайнере, что сделало его нулевым в дизайнере, а также решило проблему немедленно.

Я пытаюсь удалить выбранную строку gridview с помощью LINQ (No LINQDataSource).

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

try
{           
    var query = from i in db.QuestionModules 
                where i.QuestionModuleID == QuestionModuleID 
                select i;

    QuestionModule o = query.First();
    db.QuestionModules.DeleteOnSubmit(o);
    db.SubmitChanges();
}

Это исключение я получаю:

System.Data.Linq.ChangeConflictException: Row not found or changed. at
System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode
failureMode) at
System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges() 

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

Любые идеи о том, что делать?


Answer #1

Для меня это был столбец перечисления (сопоставленный с varchar), который вызвал проблему, поэтому мне пришлось пройти проверку обновлений, чтобы никогда.


Answer #2

Как указано в @ dherrin79, это может быть вызвано из-за точности дисперсии между базой данных и кодом. Для меня проблема заключалась в том, что столбец базы данных должен был быть десятичным (10,2), но он был создан как десятичный (18,0). Это было для денежного поля, поэтому, возможно, я должен был использовать тип столбца денег.

Итак, я сохранил сумму в долларах, например 3,14 доллара, но десятичный разделился. Это привело к изменению значения базы данных и не соответствует значению в C #.

Надеюсь это поможет.


Answer #3

ОК - похоже, что (по крайней мере, в моем случае) ответ заключался в том, чтобы установить для свойства UpdateCheck не первичного ключа значение Never в DBML-файле. Это немедленно устранило проблему «Строка не найдена или не изменена».

Учитывая слухи о том, что Microsoft является мотылькой Linq-To-Sql в пользу Entity Framework, задается вопросом, будут ли исправлены эти виды ошибок?


Answer #4

Проблема была в том, что у меня был тип DateTime в .net framework, но в нашем поле базы данных был тип DateTime2, который является более высокоточным типом данных. Поэтому, когда мы будем вводить изменения, поля даты объекта и БД находились всего в нескольких наносекундах, что могло бы вызвать ошибку параллелизма. Это произошло, когда мы перешли на новую версию MSSQL и конвертировали наши поля DateTime в DateTime2.

Итак, в нашем коде, где у нас были:

    Obj.DateUpdated = DateTime.Now()

Мы изменили его на:

    Obj.DateUpdated = DateTime.Parse(DateTime.Now.ToString())

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


Answer #5

Проблема также может заключаться в том, что определение таблицы DBML не соответствует статусу определения базы данных. Я просто удалил модель DBML и снова вставил ее из базы данных, и она сработала.

Надеюсь, это поможет кому-то.


Answer #6

Также - если вы вызываете метод выбора для linqdatasource и вручную устанавливаете e.result, убедитесь, что вы также включаете любые значения других ключей.

Ничто другое не работало для меня, но это.


Answer #7

У меня была аналогичная проблема, и хотя удаление и повторное добавление таблицы / класса DBML помогло некоторым пользователям, для меня это было немного иначе, поскольку я использую WCF с отдельным объектом и ListView на клиенте.

Если я использовал .Attach (сущность), он потерпел неудачу - «Строка не найдена или изменена». Но при использовании .Attach (entity, original) она работает каждый раз

public void DeleteTask(Task task)
    {
        TwoDooDataContext db = new TwoDooDataContext();
        db.Tasks.Attach(task,GetTaskByID(task.ID));
        db.Tasks.DeleteOnSubmit(task);
        db.SubmitChanges();
    }

Answer #8

У меня такая же проблема, и я столкнулся с этим блоком , который в основном утверждает, что у Linq-To-Sql есть проблема в его оптимистичном параллелизме, где:

  1. Используются поля высокой точности datetime. Решение состоит в том, чтобы установить UpdateCheck никогда не для этого столбца, ваш DBML-файл
  2. Столбцы GridView, которые настроены на невидимость, получают доступ к свойству объекта данных (эта вторая причина не имеет смысла, но, похоже, это весь ярость в этом блоге).

Я еще не пробовал эти решения, но вернусь сюда, когда найду.


Answer #9

Убедитесь, что никакие столбцы не содержат null значений в связанной таблице (т. Е. Таблицу, подлежащую обновлению).


Answer #10

Я обошел эту проблему, убедившись, что я обновил свой объект непосредственно перед его обновлением. Я делаю это с помощью опции KeepChanges.

    db.Refresh(System.Data.Linq.RefreshMode.KeepChanges, employee);

Answer #11

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

Мы используем пользовательский T4 для нашего Linq to SQL dbml. Мы в основном просто модифицировали исходный get / set свойств строки, чтобы автоматически обрезать и установить нуль.

        get { return _OfficiantNameMiddle.GetValueOrNull(); }
        set 
        {
            value = value.GetValueOrNull();
            if (_OfficiantNameMiddle != value) 
            {
                _IsDirty = true;
                OnOfficiantNameMiddleChanging(value);
                SendPropertyChanging("OfficiantNameMiddle");
                _OfficiantNameMiddle = value;
                SendPropertyChanged("OfficiantNameMiddle");
                OnOfficiantNameMiddleChanged();
            }
        }

У устаревших данных в нашей базе данных были некоторые ведущие / конечные пробелы, поэтому любая проверка параллелизма в этих столбцах не приводила к совпадению (это было сравнение обрезанного значения с неизменным значением базы данных). Было очень легко профилировать SQL, захватить SQL и начать комментирование элементов в предложении WHERE до тех пор, пока он не начнет возвращать строку во время проверки параллелизма.

К счастью, у нас есть поле LastUpdatedOn в наших таблицах, которое автоматически устанавливается через OnValidate (System.Data.Linq.ChangeAction).

    partial void OnValidate(System.Data.Linq.ChangeAction action)
    {
        if (action == System.Data.Linq.ChangeAction.Insert)
        {
            CreatedBy = CurrentUserID;
            CreatedOn = DateTime.Now;
            LastUpdatedBy = CreatedBy;
            LastUpdatedOn = CreatedOn;
        }
        else if (action == System.Data.Linq.ChangeAction.Update)
        {
            LastUpdatedBy = CurrentUserID;
            LastUpdatedOn = DateTime.Now;
        }
    }

Чтобы обойти проблему, мы просто устанавливаем проверку параллелизма на «Никогда» для всех столбцов, кроме столбцов первичного ключа и столбца LastUpdatedOn. Это сработало для нас.





linq