NVARCHAR появляется как «Binary 0» после присоединения

Question

Я пытаюсь выполнить поиск на сервере MSSQL 2005 Express, где установлена ​​наша база данных WSUS. Я хотел бы получить имена файлов и значения дайджесты для текущей ревизии септических обновлений. Это запрос, я хотел бы работать:

SELECT 
    * 
FROM 
    tbRevision as rev 
    join tbLocalizedPropertyForRevision as lpfr on lpfr.RevisionID = rev.RevisionID 
    join tbLocalizedProperty as lp on lp.LocalizedPropertyID = lpfr.LocalizedPropertyID 
    join tbFileForRevision as ffr on rev.RevisionID = ffr.RevisionID 
WHERE 
    lpfr.LanguageID = 1033 and 
    rev.IsLatestRevision = 1 and 
    rev.IsBeta = 0 and 
    lp.Title like '%931125%'; 

Проблема заключается в том, что этот запрос не найдет ничего, хотя есть изменения с тем, что КБ числом в них. Если я удалю последнюю строку соединения join tbFileForRevision as ffr on rev.RevisionID = ffr.RevisionID из запроса, я верну все результаты.

Хочет знать, что было неправильно, я начал новый запрос с другой стороны, уже зная имя файла:

SELECT 
    * 
FROM 
    tbLocalizedPropertyForRevision as lpfr 
    join tbRevision as r on r.RevisionID = lpfr.RevisionID 
    join tbFileForRevision as ffr on ffr.RevisionID = r.RevisionID 
    join tbFile as f on f.FileDigest = ffr.FileDigest 
    join tbLocalizedProperty as lp on lp.LocalizedPropertyID = lpfr.LocalizedPropertyID 
WHERE 
    f.FileName like '%rootsupd%' 

В этом Resultset поля Title всегда «Binary 0» и Description и ReleaseNotes всегда заполненные с NULL, хотя LocalizedPropertyID заполнен правильно и совпадает с другим LocalizedPropertyID от tbLocalizedPropertyForRevisiontbLocalizedPropertyForRevision

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

EDIT: Ссылка на SUSDB Diagram Если вам это нужно в другом формате, расскажите, как его предоставить. Многие компании, использующие программное обеспечение Microsoft, имеют WSUS, возможно, вы сами можете получить доступ к этому серверу.

Answer 1

При отладке нескольких запросов для объединения, где большинство таблиц являются частью пункта WHERE, это помогает мне разбить запрос на части, которые можно проверить по отдельности, например, так:

SELECT * 
FROM 
    tbRevision as rev 
    left join (
     select * 
     from tbLocalizedPropertyForRevision as lpfr 
     where lpfr.LanguageID = 1033 
    ) as lpfr 
     on lpfr.RevisionID = rev.RevisionID 
    left join (
     select * 
     from tbLocalizedProperty as lp 
     where lp.Title like '%931125%' 
    ) as lp 
     on lp.LocalizedPropertyID = lpfr.LocalizedPropertyID 
    left join (
     select * 
     from tbFileForRevision 
    ) as ffr 
     on rev.RevisionID = ffr.RevisionID 
WHERE 
    rev.IsLatestRevision = 1 and 
    rev.IsBeta = 0 

Запуск выше дал бы мне все записи, соответствующие критериям таблицы rev. (Левые соединения гарантируют, что я все получу.)

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

Тогда я хотел бы изменить, соединяющиеся обратно left join и добавить к статье WHERE в самом низу:

and lpfr.LanguageID = Is Null 

, чтобы показать мне, чего не хватает, что я, возможно, не хотят, чтобы отсутствовать.

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

select * 
    from tbLocalizedPropertyForRevision as lpfr 
    where lpfr.LanguageID = 1033 

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

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

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