Обнуляемые поля bool в связанных таблицах MS Access

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

Я работаю в Access 2010, используя связанную таблицу с базой данных SQL Server 2005 (через канал ODBC SQL Server). В этой таблице одно из логических полей помечено как допускающее значение NULL, и несколько записей в этой таблице действительно имеют значение NULL в поле. Все идет нормально.

Входит Access, и как только вы открываете связанную таблицу, Access показывает 0 (ложь) вместо пустой ячейки (проблема №1). И если вы попытаетесь изменить что-либо в записи, вы получите сообщение об ошибке, в котором говорится, что запись была изменена кем-то другим, и ваши изменения не могут быть сохранены. Эта последняя проблема связана с тем, что Access не допускает пустых полей типа bool и немного теряет рассудок при попытке сохранить значение.

Мои исследования показывают, что это может иметь какое-то отношение к Access, использующему Jet в фоновом режиме для подключения к базе данных SQL Server, а Jet, по-видимому, не поддерживает значения типа bools, допускающие значение NULL. Похоже, что нет способа настроить Jet для поддержки этого (хотя, возможно, есть, если вы подключаетесь в коде). Я также думал, что MS заменяет Jet другой технологией, используемой в Office 2010 (я думаю, ACE), но не могу сказать, действительно ли это используется Access. В любом случае я не могу найти настраиваемых параметров, касающихся bools, допускающих значение NULL.

Наконец, эта проблема, похоже, была передана в MS совсем недавно, но с их стороны нет ответа: https://connect.microsoft.com/SQLServer/feedback/details/617339/null-бит-поля-создают-ложные-ms-ошибки-доступа-при-использовании-родном-odbc-драйвере?wa=wsignin1.0#tabs

Мне интересно, сталкивался ли кто-нибудь еще с этим и нашел решение. И прежде чем вы предложите это, отключение параметра NULL и установка для всех NULL значения false - это не вариант в нашем случае. Для нас значение null на самом деле является допустимым состоянием и сильно отличается от false.

Спасибо!


nullable sql-server ms-access ms-jet-ace
person David Catriel    schedule 21.01.2011    source источник
comment
Это известная проблема, начиная с Access 97: support.microsoft.com/kb/278696/EN -США. Поскольку за последние 14 лет ничего не изменилось, я не ожидал бы каких-либо исправлений в ближайшее время ...   -  person Heinzi    schedule 28.10.2011

Ответы (3)


arrow_upward
6
arrow_downward

ACE - это обновление Jet (созданное на основе кодовой базы Jet 4.0, которая поддерживается командой Windows и не ведется дальнейшего развития, в то время как ACE полностью разрабатывается командой Access). Он не сильно отличается от Jet, за исключением того, что это новая версия ядра базы данных и функции, которых не хватало Jet.

Обнуляемые логические значения не являются одной из дополнительных функций. В любом случае, если я не ошибаюсь, существуют большие теоретические споры о том, должны ли логические значения быть Nullable, а Jet / ACE приходит на сторону, которая говорит, что этого не должно быть.

Логические значения, не допускающие значения NULL, вызывают проблемы даже в Access / Jet / ACE (Аллен Браун обсуждал одно такое, с LEFT JOINs < / а>). Я предлагаю вам изменить поле на Nullable Bit, Byte или Integer (я не уверен, какие именно типы данных есть в SQL Server и что будет наиболее совместимо с Access / Jet / ACE).

В качестве альтернативы вы можете подойти к этому способу решения проблемы BIGINT, используя представление для CAST () логического значения на стороне сервера для INT. Это делает его недоступным для редактирования, но (как и в случае с BIGINT) вы можете сохранить исходное поле в VIEW и записать в него соответствующие значения, в то время как версия CAST () предназначена только для отображения.

Как бы то ни было, SSMA для доступа увеличивает размер логических значений Jet / ACE до битовых полей, допускающих значение NULL (хотя я не уверен, почему они допускают значение NULL - мне может потребоваться проверить некоторые из моих приложений, чтобы убедиться, что они работают правильно!).

person David-W-Fenton    schedule 22.01.2011
comment
Я думаю, что Nullable Bit - это нормально. - person Patrick Honorez; 25.01.2011
comment
Привет, извините за поздний ответ. Я проверил нашу базу данных SQL, и это уже бит, допускающий значение NULL. Нет другого типа поля, который позволил бы хранить в нем данные логического типа, если только я не выберу int, допускающий значение NULL, и не наложу на него ограничение 0/1. Это вариант, но он имеет последствия в других местах. Не мой первый выбор. - person David Catriel; 28.01.2011
comment
Повторите комментарий о повышении размера логических значений SSMA до битов, допускающих значение NULL - не могли бы вы немного подробнее рассказать об этом? Вы имеете в виду таблицу Access с полями типа bool, которые интерпретируются как бит, допускающий значение NULL, при подключении к таблице thios? Я иду в другом направлении - моя таблица находится в SQL Server, и я использую Access для подключения к ней ... - person David Catriel; 28.01.2011
comment
Когда вы используете SSMA для увеличения размера таблицы Acesss с помощью логического поля, она создается в SQL Server как битовое поле, допускающее значение NULL. На самом деле, чтобы отобразить 100% правильно, это должно быть битовое поле, не допускающее обнуления, поскольку логическое поле Jet / ACE не допускает обнуления, поэтому это не перевод 1: 1. Но, цитируя это, я подчеркивал, что MS считает, что это наиболее близкое соответствие при увеличении размера, поэтому он должен быть наиболее совместимым типом данных для внешнего интерфейса Access для SQL Server. - person David-W-Fenton; 29.01.2011

arrow_upward
0
arrow_downward

Следуя анализу в этой статье базы знаний Майкрософт, http://support.microsoft.com/kb/318882 здесь вот что мы сделали, чтобы решить эту проблему. 1) Мы запустили sql-скрипт для обновления строк в этой таблице, у которых были нули в битовых полях, 2) Затем мы изменили определение таблицы, включив в эти битовые поля значение по умолчанию «0».

person J Thomas    schedule 15.02.2011
comment
Это интересная статья. У меня не было таких проблем с последней увеличенной мной базой данных (использующей A2003 с SQL Server Express 2008 R2), и я не указывал значение по умолчанию для логических полей. Мне нужно будет сделать проверку, но если бы возникла указанная проблема, я бы получал отчеты об основных ошибках в течение последних 6 месяцев (чего у меня не было), поэтому похоже, что должно быть что-то еще . Возможно, что-то изменилось между SQL 2005 и 2008. Интересно, есть ли у всех ваших таблиц PK и поле отметки времени? - person David-W-Fenton; 16.02.2011

arrow_upward
0
arrow_downward

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

Сегодня я нашел решение, используя следующий сквозной запрос:

SELECT 
    *,  
    CASE MYFIELD 
       WHEN NULL THEN NULL 
       WHEN 1 THEN 1 
       WHEN 0 THEN 0 
    END AS MYRESULT
FROM 
    DBO.MYTABLE

Это не обновляется, но в любом случае там работают обычные операторы SQL.

person Çağlar Durgun    schedule 01.10.2019