MS-Access - Pourquoi cette requête de mise à jour ne peut-elle pas remplir les cellules vides?

Question

Dans la base de données MS-Access, table appelée NewTable3

colname est une colonne de texte contenant un lot de cellules ou d'espaces vides.

Je veux mettre? caractère dans les cellules vides. lorsque je lance la requête

UPDATE NewTable3 SET colname = '?' WHERE ISNULL(colname) ; 

Cette requête met à jour les 0 enregistrements pourquoi. ce qui ne va pas avec cette requête

Answer 1

Deux choses rapides:

1) Essayez de mettre la colname entre crochets. 2) Souvenez-vous que les cellules vides (Nulls) et les chaînes vides ("") sont différentes.

Ensemble:

UPDATE NewTable3 SET [colname] = "?" WHERE ISNULL([colname]) OR [colname] = ""; 

, sont également vous en cours d'exécution de la requête dans Access lui-même, ou tout simplement en utilisant le moteur d'accès et l'utilisation des données dans un autre programme/via un script VBA? Ca peut faire la différence.

Answer 2

Essayez:

UPDATE NewTable3 SET colname = '[?]' WHERE ISNULL(colname); 

Le questionmark est utilisé pour les paramètres anonymes, vous devez donc échapper comme ci-dessus. Notez que je n'ai pas essayé cela.

Answer 3

UPDATE NewTable3 SET NewTable3.colname = "?" 
WHERE (((NewTable3.colname) Is Null)); 

Pour garder votre fonction: OÙ (((IsNull ([NewTable3.colname])) = true));

Answer 4

EDIT:

Basé sur aiguillon de @ onedaywhen, je vois maintenant que je jamais complètement absorbé la question initiale, qui demandait de remplacer les valeurs nulles avec le littéral? personnage. C'est fou et pas utile ou utile. Si vous n'avez pas de valeur par défaut significative pour le champ, alors LAISSEZ NUL. Si vous voulez faire la distinction entre Nul (inconnu) et Vide (c'est-à-dire, être connu comme étant vide), vous pouvez autoriser des chaînes de longueur nulle et changer les Nuls en ZLS.

Mon suit message original, car je pense qu'il est utile pour les personnes qui pourraient arriver à cette question folle besoin de faire les choses correctement:

---

Au total, toutes les réponses dans ce fil finissent par résoudre tous les les problèmes avec l'instruction SQL d'origine, mais ils le font incomplètement, donc je vais les compiler tous ensemble dans le but de créer une réponse correcte complète.

@Wim Hollebrandse souligne avec sagesse qu'un paramètre a besoin entre parenthèses, mais affiche la SQL comme:

UPDATE NewTable3 SET colname = '[?]' WHERE ISNULL(colname); 

Ceci est incorrect, en ce que les citations causera ce qui leur est à l'intérieur à traiter littéralement, au lieu d'évaluer en tant que paramètre, vous vous retrouverez avec tous vos champs mis à jour à la valeur littérale "[?]". La syntaxe correcte serait:

UPDATE NewTable3 SET colname = [?] WHERE ISNULL(colname); 

@GuinnessFan signale un problème dans la clause WHERE, ce qui suggère que le résultat de IsNull() doit être comparé à vrai pour que la clause WHERE de travailler.En d'autres termes, ceci:

WHERE IsNull(NewTable3.colname) 

... devrait être ceci:

WHERE IsNull(NewTable3.colname)=True 

Mais étant donné que les deux déclarations évaluent les mêmes, ils sont tout à fait équivalent. Mais @GuinnessFan est exact que c'est la meilleure syntaxe:

WHERE NewTable3.colname Is Null 

@mavnn souligne que les champs peuvent être « vide » sans être nul, ce qui est un problème très commun. Je crois en principe (et conforme à ma compréhension des normes SQL officielles) que les champs devraient être initialisés comme Null et ne devraient pas autoriser les chaînes de longueur nulle. Il est certainement possible dans certaines applications de vouloir distinguer Null, c'est-à-dire, valeur non encore fournie, de blanc (chaîne de longueur nulle), c'est-à-dire, valeur connue pour être vide. Mais si cela fait partie de la conception de l'application, alors l'utilisateur doit savoir que les critères sur ces champs doivent considérer si l'un ou les deux doivent être inclus (c'est-à-dire Null et <> "" ou l'un ou l'autre). De mon point de vue, il était regrettable que l'ancien par défaut pour les champs de texte (où AllowZLS est par défaut FALSE) a été modifié dans Access 2003 pour permettre ZLS par défaut. Cela signifie que beaucoup de personnes qui ne remarquent pas que AllowZLS a la valeur TRUE quand elles créent leurs tables finissent avec ZLS stockées dans leurs champs de texte sans avoir l'intention de le faire (et importer une table d'une version précédente vaut TRUE).

Lors du test de Null et = "", la clause WHERE qui recherche tous les champs "vides" fonctionne comme prévu, le correctif permanent consiste à modifier la définition du champ pour interdire les ZLS. Mais notez que le fait de changer AllowZLS en FALSE ne supprime pas les ZLS existants - vous devez exécuter une mise à jour SQL pour les supprimer. Enfin, en utilisant des paramètres, il est préférable de les déclarer de telle sorte que les valeurs que l'utilisateur peut entrer soient limitées aux valeurs appropriées. Si le champ est numérique, vous limiter à des valeurs numériques, si une date, les valeurs de date, si le texte ou mémo, au texte:

PARAMETERS [User Prompt] Long; 
    UPDATE MyTable SET LongIntegerColumn = [User Prompt] 

    PARAMETERS [User Prompt] DateTime; 
    UPDATE MyTable SET DateColumn = [User Prompt] 

    PARAMETERS [User Prompt] Text (255); 
    UPDATE MyTable SET TextColumn = [User Prompt] 

Notez que avec le texte (255) comme type de paramètre, quoi que ce soit fourni par l'utilisateur est tronqué à 255 caractères, même si c'est plus long que cela (ce serait une situation assez inhabituelle où vous auriez besoin de cela). Pour les valeurs plus que (comme les champs mémo), vous omettez la déclaration de la longueur du texte:

PARAMETERS [User Prompt] Text; 
    UPDATE MyTable SET TextColumn = [User Prompt] 

En tout état de cause, je pense que l'on appelle des paramètres anonymes ne sont pas trop utile, car vous n'êtes pas tirant parti de la puissance des paramètres pour restreindre le type de données des critères d'entrée.

Answer 5

Je ne crois pas que le remplacement de la valeur NULL par votre propre valeur «magique» ? vous causera autre chose que de la douleur supplémentaire.

En espérant vous inspirer de cet article:

How To Handle Missing Information Without Using (some magic value)