Champs booleans nullables dans les tables liées MS Access

On dirait que je ne suis pas le seul à avoir ce problème, mais il ne semble pas y avoir de réponse à ce problème.

Je travaille dans Access 2010, en utilisant une table liée à une database SQL Server 2005 (via un canal ODBC SQL Server). Dans cette table, l'un des champs booleans est marqué comme nullable, et plusieurs loggings dans cette table ont en fait une valeur nulle dans le champ. Jusqu'ici tout va bien.

Dans vient Access, et dès que vous ouvrez la table liée, Access affiche un 0 (faux) au lieu d'une cellule vide (problème # 1). Et si vous essayez de modifier quelque chose dans l'logging, vous obtenez un message d'erreur indiquant que l'logging a été modifié par quelqu'un d'autre et que vos modifications ne peuvent pas être enregistrées. Ce dernier problème est dû au fait qu'Access ne tolère pas les champs booleans nullables, et devient un peu fou en essayant d'save la valeur.

Ma search montre que cela pourrait avoir quelque chose à voir avec Access utilisant Jet en arrière-plan pour se connecter à la database SQL Server, et Jet ne supporte apparemment pas les booleans Nullable. Il ne semble pas y avoir un moyen de configurer Jet pour supporter ceci (bien qu'il y en ait peut-être, si vous vous connectez en code). Je pensais aussi que MS remplaçait Jet avec une autre technologie utilisée dans Office 2010 (ACE, je pense), mais je ne sais pas si c'est ce qui est réellement utilisé par Access. Dans les deux cas, je ne trouve aucune option configurable concernant les booleans nullables.

Enfin, ce problème semble avoir été signalé à MS il y a peu de time, mais il n'y a pas de réponse de leur côté: https://connect.microsoft.com/SQLServer/feedback/details/617339/null-bit-fields-produce -spurious-ms-access-errors-lors de l'utilisation du driver natif-odbc? wa = wsignin1.0 # tabs

Je me request si quelqu'un d'autre a été confronté à cela et a trouvé une solution. Et avant de le suggérer, désactiver l'option nullable et mettre tous les nulls à 'false' n'est pas vraiment une option dans notre cas. Pour nous, null est en fait un état valide et très différent de 'faux'.

THX!

ACE est une mise à niveau de Jet (dérivée de la base de code Jet 4.0, qui est maintenue par l'équipe Windows et ne voit aucun développement ultérieur, tandis que ACE est en cours de développement complet par l'équipe Access). Il n'est pas significativement différent de Jet, sauf qu'il s'agit d'une nouvelle version du moteur de database et de fonctionnalités qui manquaient à Jet.

Les booleans nullables ne sont pas une des fonctionnalités supplémentaires. Dans tous les cas, si je ne me trompe pas, il y a de grands arguments théoriques pour savoir si les Booléens devraient être Nullable et Jet / ACE tombe du côté qui dit qu'ils ne devraient pas l'être.

Les booleans non nullables causent des problèmes même dans Access / Jet / ACE ( Allen Browne en a discuté avec les JOIN LEFT ). Ma suggestion est que vous changiez le champ en un champ Nullable Bit, Byte ou Integer (je ne suis pas sûr quels types de données sont dans SQL Server, ni ce qui sera le plus compatible avec Access / Jet / ACE).

Alternativement, vous pouvez l'aborder de la façon dont le problème BIGINT est traité en utilisant une vue à CAST () le boolean côté server à un INT. Cela le rend non-éditable mais (comme avec BIGINT), vous pouvez garder le champ d'origine dans la vue et écrire dedans avec les valeurs appropriées, alors que la version de CAST () est pour l'affichage seulement.

Pour ce que ça vaut, le SSMA pour Access fait migrer les booleans Jet / ACE vers des champs binarys nullables (je ne sais pas pourquoi ils sont Nullable, cependant – je devrais vérifier certaines de mes applications pour m'assurer qu'elles fonctionnent correctement!).

Suite à l'parsing dans ce Microsoft KB http://support.microsoft.com/kb/318882 voici ce que nous avons fait pour résoudre ce problème. 1) Nous avons exécuté un script sql pour mettre à jour les lignes de cette table qui avaient des valeurs nulles dans les champs binarys, 2) Nous avons ensuite modifié la définition de table pour inclure une valeur par défaut de '0' dans ces champs binarys.