База данных VIEW не отражает данные в основной таблице

Question

Введите:

Клиент утверждает, что приложение (.NET) при запросе некоторых данных возвращает данные, отличные от того, когда клиент просматривает таблицу данных напрямую.

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

Возможно ли для ПРОСМОТРА показывать данные, которые не соответствуют базовым таблицам (таблицам)?

• Каковы возможные причины / причины этого?
• Может ли оператор UPDATE в представлении заставить будущие SELECT возвращать «обновленные» данные, тогда как таблица на самом деле этого не делает?

Возможные причины (просьба прокомментировать те, у кого есть вопросительные знаки):

1. причина в том, что есть две отдельные транзакции, которые объясняют путаницу клиентов.
2. базовая таблица была изменена, но представление не было обновлено (с использованием sp_refreshview)
3. другой пользователь подключается и может видеть разные данные из-за разрешений?
4. ошибка программиста: неправильные таблицы / столбцы, неправильные фильтры (все в одном здесь)
5. происходит повреждение: DBCC CHECKDB должен помочь
6. может SELECT ... FOR UPDATE вызвать это ???
7. ? __

Что на самом деле произошло (ОТВЕТ):

Позиции столбцов были изменены в некоторых таблицах: очевидно, клиент предоставил полный доступ к базе данных консультанту для анализа использования базы данных. Этот великий парень изменил порядок столбцов, чтобы увидеть несколько полей audit в начале таблицы при использовании предложений SELECT * ....

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

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

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

Answer 1

Да, вроде.

Возможные причины:

1. Представление необходимо обновить или перекомпилировать. Происходит, когда определения исходного столбца изменяются и View (или что-то, от чего это зависит) использует "*", может быть неприятно. Вызовите sp_RefreshView. Может также произойти из-за представлений или функций (источников данных), которые он тоже вызывает.

2. Вид смотрит на что-то отличное от того, что они / вы думаете. Они смотрят не на ту таблицу или представление.

3. Представление преобразует данные неожиданным образом. Это работает правильно, просто не так, как они ожидали.

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

5. Они смотрят не на ту базу данных или с идентификатором входа / пользователя, который заставляет View изменять то, что он показывает.

Answer 2

возможно, если базовая таблица была изменена и sp_refreshview не был запущен для представления, поэтому представление будет иметь пропущенные столбцы, если они были добавлены в таблицу.

Чтобы понять, что я имею в виду, прочитайте как убедиться, что представление будет иметь базовые изменения таблицы, используя sp_refreshview

Answer 3

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

Еще одна возможность, которую пользователи, похоже, не понимают, заключается в том, что данные текучие. Данные, которые вы читаете в 3:00 в представлении, могут не совпадать с данными, которые вы видите в 3:30 при непосредственном просмотре таблицы, поскольку в это время произошли изменения.

Answer 4

Несколько возможностей:

• Ваше приложение .NET может не указывать, куда вы или они думают, что оно указывает. Например, он указывает на тестовый сервер по ошибке

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

• Параметр ANSI_NULLS относится к представлению при его создании. Если он отличается от настройки во время выбора (ей) в базовых таблицах, это может привести к расхождениям для определенных типов запросов

• Базовые структуры таблиц изменились, и представление не обновилось (особенно это проблема, если используется «SELECT *»)

Я отредактирую этот пост, если подумаю о других.

РЕДАКТИРОВАТЬ: Вот пример того, как параметр ANSI_NULLS может отбрасывать ваши результаты:

SET ANSI_NULLS ON

DECLARE
     @i     INT,
     @j     INT

SET @i = NULL
SET @j = 1

SELECT
     CASE WHEN @i <> @j THEN 'Not Equal' ELSE 'Equal' END

SET ANSI_NULLS OFF

SELECT
     CASE WHEN @i <> @j THEN 'Not Equal' ELSE 'Equal' END

Результаты, которые вы должны получить:

Equal

Not Equal

Answer 5

Предполагая, что представление на самом деле не преобразует данных, технически это возможно, если происходит повреждение. Представление извлекает данные из одного индекса, «таблица» извлекает из другого (т. Е. Из кластеризованного), и эти два несинхронизированы. DBCC CHECKDB должен выявить проблему.

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

Answer 6

Наверняка есть и другие вещи:

1) Derived attributes are pulling from wrong tables in the view
2) The view is using incorrect tables
3) incorrect or missing joins in the view

чтобы назвать несколько