Localisation de ms et valeurs booléennes par défaut

Question

Notre client d'accès génère à la volée des instructions SQL, des instructions de mise à jour et de suppression à envoyer sur un serveur MS-SQL. La plupart des utilisateurs ont la version d'exécution d'Access 2007 et quelques-uns utilisent la version complète MS-Access, 2003 ou 2007. Ce matin, un de nos nouveaux utilisateurs à l'étranger, utilisant une version française/complète d'Access 2003, n'a pas pu mettre à jour champs booléens.

Il est apparu que ces champs sont, dans la version française d'Access, remplis de valeurs "Vrai/Faux" au lieu de "Vrai/Faux". Le problème a été résolu en installant le 2007 runtime d'accès. Mais je voudrais trouver une solution permanente, où je serais capable de lire quelque part quelle version localisée d'Access est utilisée et de 'traduire' les valeurs localisées True/False en True/False standard. J'ai déjà vérifié les paramètres régionaux de l'ordinateur sans succès, donc c'est ailleurs. Une idée?

EDIT: Après la proposition JohnFX, il est effectivement possible de convertir vrai local/Faux Universal Vrai/Faux avec cette fonction simple:

Function xBoolean(xLocalBooleanValue) as Boolean 
if cint(xLocalBooleanValue) = -1 Then 
    xBoolean = True 
endif 
if cint(xLocalBooleanValue) = 0 Then 
    xBoolean = False 
endif 
end function 

EDIT: après @ commentaires de David, j'ai changé la solution préférée . Sa proposition est plus intelligente que la mienne.

EDIT: Je reçois les Vrai/Faux valeurs en lisant la valeur d'un champ dans un recordset:

? debug.print screen.activeForm.recordset.fields(myBooleanField).value 
Vrai 

Answer 1

La valeur True n'est PAS FALSE, ou NOT 0, dans tous les cas, quelle que soit la localisation ou le format de la base de données. Donc, si vous remplacez tous les tests pour True avec NOT 0 et tous les tests pour False avec = 0, alors vous avez évité la question de la localisation des mots-clés Access (je suis surpris que VBA et Jet and Access Cependant, les services d'expression ne comprendraient toujours pas True/False), ainsi que la convention utilisée par votre moteur de base de données pour stocker des valeurs booléennes.

En général, votre couche d'accès aux données doit être abstraite pour vous. Les deux ODBC et ADO le font automatiquement, donc vous travaillez avec les valeurs booléennes que vous connaissez et cela est pris en charge pour vous de manière transparente, selon mon expérience. Je suis également toujours perplexe à propos de la question, car cela ressemble à un problème d'affichage/formatage, mais utilisez NOT 0 et = 0 pour True et False évite entièrement le problème dans tous les cas.

EDIT: En ce qui concerne la fonction éditée dans la question de Philippe:

Y at-il une raison que vous avez implicitement défini le paramètre de votre fonction en tant que variante? C'est ce que tu veux dire? Si elle est passée à une valeur Null, elle se déconnecte du premier CInt(), car CInt() ne peut pas accepter un Null.

En outre, il existe un problème logique en ce que VBA n'importe quel nombre mais 0 est censé renvoyer True. C'est aussi du code complètement redondant.Ceci est plus simple et renvoie le résultat correct dans tous les cas:

Function xBoolean(xLocalBooleanValue As Vriant) as Boolean 
    If CInt(xLocalBooleanValue) <> 0 Then 
     xBoolean = True 
    End If 
    End Function 

Ou, pithier encore:

Function xBoolean(xLocalBooleanValue As Variant) as Boolean 
    xBoolean = (CInt(xLocalBooleanValue) <> 0) 
    End Function 

Et pour gérer les valeurs NULL passé dans le paramètre:

Function xBoolean(xLocalBooleanValue As Variant) as Boolean 
    xBoolean = (CInt(Nz(xLocalBooleanValue, 0)) <> 0) 
    End Function 

Je suis Je ne suis pas sûr que ce soit nécessaire dans le contexte où vous l'utilisez actuellement, mais je déteste toujours écrire du code où je peux imaginer un cas où il y aura erreur - même si je sais qu'il ne peut pas casser dans son contexte actuel, on ne sait jamais où il pourrait finir par s'habituer, alors si vous anticipez une condition qui peut être traitée, vous devriez le gérer.

Optimisation prématurée? Non - c'est de mettre un verrou de sécurité sur une arme qui l'empêche d'être mal utilisé.

(d'autre part, si elle a plus de lignes de code pour gérer l'erreur antipated que la fonction a commencé avec, je pense à deux fois)

Answer 2

Avez-vous envisagé d'utiliser -1/0 (Access est bizarre booléens) au lieu de vrai/false dans vos requêtes de mise à jour et de suppression?

Math est le langage universel, yaknow.

De même, pour éviter de devoir trop localiser l'interface utilisateur, pourquoi ne pas utiliser des cases à cocher au lieu d'un champ de texte pour les booléens de votre interface utilisateur?

Answer 3

simple:

Function xBoolean(bool As Variant) As Boolean 
    xBoolean = Abs(Nz(bool, 0)) 
End Function