Объекты, на которые ссылается LinqToSql, будут генерировать исключение NullReferenceException

Question

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

На моей машине для разработки все работало нормально (ссылки были загружены отлично), но вчера вечером я загрузил изменения на наш производственный сервер и начал получать исключения NullReferenceException при попытке получить доступ к ссылке в моих таблицах.

Пример кода:

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'd, но я дважды проверил все безрезультатно (кроме того, он работает на моей коробке).

(На сервере и на моем компьютере все одинаково, одни и те же библиотеки DLL, схема БД и т. Д. ...) (Я на самом деле скопировал весь файл DBF на мой сервер, так что это точно такая же схема)

Answer 1

Включили ли вы контекстный вход в систему и сравнили результаты на вашем компьютере разработчика с результатами на вашем рабочем компьютере?

Answer 2

Чтобы найти и решить подобную проблему, было бы полезно использовать трассировку стека и, возможно, профилирование базы данных.

Возможно, проблема связана с безопасностью. Вы пытались войти в систему с теми же учетными данными в Management Studio, что и ваше приложение, и сделать выбор в таблице.

Это, по крайней мере, даст вам представление о безопасности или проблеме linq.

Answer 3

Если вы перенесете свой источник на рабочий сервер и скомпилируете его там, попробуйте восстановить сгенерированный источник для DataContext. Вы можете сделать это, запустив «запустить пользовательский инструмент» из контекстного меню вашего исходного файла DataContext.

Если оба совместно используют один и тот же двоичный файл, убедитесь, что определение базы данных точно совпадает в обеих базах данных. Небольшая разница, как то, что один столбец обнуляется на вашем рабочем сервере, но не обнуляется на вашем devbox, может иметь все значение.

Answer 4

Одна из возможностей заключается в том, что используемая вашим DBML строка подключения по-прежнему указывает на сервер базы данных, отличный от Production.

Это случалось с нами всякий раз, когда LinqDataSource использовался непосредственно на странице ASPX, и, таким образом, DataContext использовал конструктор по умолчанию, который указывал на строку подключения на основе базы данных, которую последний разработчик использовал для импорта DBML.

Мы создали объект DataContext, унаследованный от сгенерированного DataContext, и заменили конструктор по умолчанию правильной строкой подключения из нашего web.config.

Answer 5

Изучить время существования DataContext. Здесь может работать устаревший кеш

Например:

1. Context1: загрузить Sale с идентификатором == 1. Проверьте его свойство User и наблюдайте за нулевым пользователем.
2. Context2: загрузка продажи с идентификатором == 1. Измените свойство пользователя, добавив нового пользователя. Commit.
3. Context1: загрузить Sale с идентификатором == 1. Проверьте его свойство User. Да, все еще ноль (это кешируется !!).