Строка не найдена или изменена ошибка LINQ C# в простой инструкции
во-первых, нет никаких шансов, что это многопользовательская проблема, поскольку я работаю локально над версией базы данных dev.
Я получаю не очень объяснительную Row not found or changed ошибка при выполнении db.Метода submitchanges(). Если я нарушу выполнение непосредственно перед тем, как произойдет SubmitChanges (), я могу проверить SQL Server Management Studio и строку тут!
вот код для всей функции, просто чтобы поместить его в контекст для любого кто хочет помочь, но проблема в самом конце (строка 48).
обновление это действительно странно: ошибка вызвана обновлением matchingTrans.Url (см. предпоследнюю строку кода). Комментирование этой строки не вызывает ошибки-даже если matchingTrans.Название все еще обновляется.
private static void MenuItemUpdate(int languageId, NavigationItem item)
{
using (var db = DataContextFactory.Create<MyDataContext>())
{
// Select existing menu item from database.
var dbItem =
(from i in db.MenuItems
where i.Id == item.Id
select i).Single();
// Obtain ID of link type.
dbItem.FkLinkTypeId = GetLinkTypeByName(
Enum.GetName(typeof (NavigationItemLinkType), item.LinkType)).Id;
// Update the Link field with what is given.
dbItem.Link = item.Link;
db.SubmitChanges();
// Item already exists and needs editing.
// Get associated translations.
var trans =
from t in db.MenuItemTranslations
where t.FkMenuItemId == item.Id
select t;
// If translation exists for given language, edit it.
var matchingTrans =
(from t in trans
where t.FkLanguageId == languageId
select t).SingleOrDefault();
if (matchingTrans == null)
{
// No matching translation - add one.
var newDbTrans = new MenuItemTranslation
{
FkMenuItemId = item.Id,
FkLanguageId = languageId,
Title = item.Title,
Url = item.FriendlyUrl
};
db.MenuItemTranslations.InsertOnSubmit(newDbTrans);
db.SubmitChanges();
}
else
{
// Matching translation - edit it.
matchingTrans.Title = item.Title;
matchingTrans.Url = item.FriendlyUrl;
db.SubmitChanges();
// WTF ERROR: Row not found or changed.
}
}
}
4 ответов
глядя На Выходные данные SQL Profiler, это помогло мне понять ответ на это. Был сгенерирован плохой кусок SQL, который закончился на WHERE 0 = 1 ... очевидная ошибка.
оказывается, что поле было просто изменено, чтобы разрешить нулевые значения другим разработчиком, и файл Linq-to-SQL не был обновлен соответствующим образом.
короче, если Row not found or changed сообщение об ошибке создается без причины,убедитесь, что ваша схема базы данных точно соответствует ваш.файл dbml иначе вы получите это сообщение об ошибке в любых полях, которые имеют несколько отличающиеся схемы.
взгляните на свойство соединения "No Count" на уровне сервера sql server
1. Щелкните правой кнопкой мыши соединение Sql server в Обозревателе объектов -->свойство
2. Перейдите на вкладку/страницу подключение
3. Найдите опцию подключения по умолчанию " нет подсчета"
4. Убедитесь, что этот параметр не установлен.
еще одна возможность, которую я нашел, чтобы добавить к отличному списку ответов здесь:
при использовании столбца not-nullable в базе данных-затем сопоставление этого с типом данных, который является внутренне nullable (в этом примере тип DB длинный BLOB не NULL сопоставляется с массивом байтов в C#), вы можете оказаться в ситуации, когда обновление базы данных с тем же самым массивом байтов вызывает эту ошибку.
пример: у вас есть сайт, который позволяет пользователю загружать изображение в базу данных. В вашей таблице есть blob (образ в sql server, что угодно), который не является nullable. Пользователь выбирает обновление записи с тем же изображением, которое уже есть. Проверка обновления завершится ошибкой. Я исправил это, сначала сделав a .SequenceEqual () проверьте, а затем только вызов .SubmitChanges () на объекте контекста, если входящий массив байтов не был равен существующему.
У меня была эта проблема, даже когда схема базы данных и dbml точно совпали. Проблема заключалась в том, что я пытался изменить сущность и вставить сущности в один оператор SubmitChanges. Я исправил это, выполнив SubmitChanges для каждой операции вместо всех сразу.
все это было в области транзакций, так что это может иметь какое-то отношение к этому, но я не уверен.