Сущности, на которые ссылаются LinqToSql, будут генерировать исключение NullReferenceException
У меня очень интересная проблема с моей моделью LinqToSql. В некоторых из моих таблиц у меня есть ссылки на другие таблицы, а в LinqToSql это представлено классом EnitiyRef, когда вы пытаетесь получить доступ к таблице ссылок, LinqToSql загрузит ссылку из базы данных.
На моей машине разработки все работало нормально (ссылки были загружены отлично), но вчера вечером я загрузил изменения на наш производственный сервер и начал получать исключения NullReferenceExceptions при попытке доступа к ссылке в моих таблицах.
Образец кода:
var sale = db.Sales.Single(s => s.ID == 1);
string username = sale.User.Name; // User is a reference to a User table
// LinqToSql will automatically load the
// row and access the fields i need.
// On my server the sale.User throws an exception that its null (User) but the user
// is definitly in the database (there is even a FK constraint from Sale to User)
Сначала я подумал, что мой DataContext получил GC, но я дважды проверил все безрезультатно (кроме того, он работает на моем поле).
(Все то же самое на сервере и в моем ящике, те же dll, та же схема db и т. д.) (Я фактически скопировал весь файл DBF на свой сервер, так что это точно такая же схема)
Те же двоичные файлы, все скомпилировано на моем ящике.
Ответы 5
Вы включили регистрацию контекста и сравнили ли результаты на своем устройстве разработчика с результатами на производственном модуле?
Спасибо за ответ. Контекст действительно показал одну вещь, что у AttributedMetaModel была другая версия на сервере, чем на моей машине, оказалось, что системный администратор установил 3.0 SP1, а не 3.5 SP1. как сбивает с толку (и как хромает). Спасибо, в любом случае.
Если вы переместите свой источник на рабочий сервер и скомпилируете его там, попробуйте повторно создать сгенерированный источник для DataContext. Вы можете сделать это, запустив «запустить пользовательский инструмент» из контекстного меню исходного файла DataContext.
Если оба используют один и тот же двоичный файл, убедитесь, что определение базы данных в обеих базах данных одинаково. Небольшая разница, например, что один столбец может иметь значение NULL на вашем производственном сервере, но не может иметь значение NULL на вашем devbox, может иметь решающее значение.
Обновил вопрос, чтобы прояснить это.
Чтобы найти и решить подобную проблему, было бы полезно использовать трассировку стека и, возможно, профилирование в базе данных.
Возможно, проблема связана с безопасностью. Вы пытались войти в Management Studio с теми же учетными данными, что и ваше приложение, и выбрать их в таблице.
Это, по крайней мере, даст вам представление о безопасности или проблеме с linq.
Пользователь, которого я использую, является владельцем базы данных. Профилировщик sql не показывает никакого трафика, кроме исходного для основной таблицы (Продажа)
Вы уверены, что правильно смоделировали, на что ссылаетесь, и что действительно существуют данные по объектам, на которые вы ссылаетесь?
Изучите время жизни DataContext. Здесь может быть устаревший кеш
Например:
- Context1: Загрузить продажу с ID == 1. Изучите его свойство User и обратите внимание на null User.
- Context2: Загрузить продажу с ID == 1. Измените свойство пользователя, добавив нового пользователя. Совершить.
- Контекст1: загрузка продажи с идентификатором == 1. Изучите его свойство пользователя. Да, все еще ноль (он кеширован !!).
Одна из возможностей заключается в том, что ваша строка подключения, используемая вашим DBML, по-прежнему указывает на сервер базы данных, отличный от Production.
Это происходило с нами всякий раз, когда LinqDataSource использовался непосредственно на странице ASPX, и поэтому DataContext использовал конструктор по умолчанию, который указывал на строку подключения на основе базы данных, которую последний разработчик использовал для импорта DBML.
Мы создали объект DataContext, который унаследовал от сгенерированного DataContext и заменил конструктор по умолчанию правильной строкой подключения из нашего web.config.
Строка подключения на самом деле такая же, но это не проблема, поскольку она основана на 127.0.0.1, поэтому она должна работать (и загружать исходный объект), кроме того, что мой сервер находится в Интернете, а я под брандмауэром.
Кстати, я использую другое решение, когда мне нужна другая строка подключения на моем производственном сервере. Я установил для строки подключения в файле DBML значение (none), это приводит к тому, что он не создает конструктор без параметров, затем я добавляю статический метод, который создает контекст со строкой из файла конфигурации.
Значит, он скомпилирован на вашем компьютере, и скомпилированная программа нормально работает на вашем компьютере, но дает сбой на рабочем сервере? (Это означает, что вы работаете из одного и того же двоичного файла или только из одного источника)