Je développe une application sur une version anglaisse de MSAccess 2003.
Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un
paramètre de type boolean:
SQLtext = "SELECT * FROM [some table]"
SQLtext = SQLtext & " WHERE ....."
SQLtext = SQLtext & " AND Imperative = " & rs!Imperative
L'application fonctionne parfaitement correctement.
Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version
française de access ACCESS que la valeur de rs!Imperative devient "Faux" au
lieu de "False". Le système affiche alors le message d'erreur:
"Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en
tant que nom de champ ou expression correcte.
Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en
"Faux"?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jean-marc
"Yabadabadoo" wrote in message news:
Hello,
Je développe une application sur une version anglaisse de MSAccess 2003. Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un paramètre de type boolean:
SQLtext = "SELECT * FROM [some table]" SQLtext = SQLtext & " WHERE ....." SQLtext = SQLtext & " AND Imperative = " & rs!Imperative
L'application fonctionne parfaitement correctement. Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version française de access ACCESS que la valeur de rs!Imperative devient "Faux" au lieu de "False". Le système affiche alors le message d'erreur: "Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en tant que nom de champ ou expression correcte.
Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en "Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas sur une chaine de caractère pour tester la valeur d'un champ Booléen et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci: SELECT * FROM Table1 WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle version d'Access, sur n'importe quelle plateforme et quelle que soit la langue.
A adapter à ton exemple bien sur, mais l'idée est la.
"Yabadabadoo" <Yabadabadoo@discussions.microsoft.com> wrote in message
news:2C85BE88-3258-4334-B228-53BD000FBB9C@microsoft.com...
Hello,
Je développe une application sur une version anglaisse de MSAccess 2003.
Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un
paramètre de type boolean:
SQLtext = "SELECT * FROM [some table]"
SQLtext = SQLtext & " WHERE ....."
SQLtext = SQLtext & " AND Imperative = " & rs!Imperative
L'application fonctionne parfaitement correctement.
Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version
française de access ACCESS que la valeur de rs!Imperative devient "Faux"
au
lieu de "False". Le système affiche alors le message d'erreur:
"Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en
tant que nom de champ ou expression correcte.
Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en
"Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas
sur une chaine de caractère pour tester la valeur d'un champ Booléen
et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci:
SELECT *
FROM Table1
WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de
la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle
version d'Access, sur n'importe quelle plateforme et quelle que soit la
langue.
A adapter à ton exemple bien sur, mais l'idée est la.
Je développe une application sur une version anglaisse de MSAccess 2003. Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un paramètre de type boolean:
SQLtext = "SELECT * FROM [some table]" SQLtext = SQLtext & " WHERE ....." SQLtext = SQLtext & " AND Imperative = " & rs!Imperative
L'application fonctionne parfaitement correctement. Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version française de access ACCESS que la valeur de rs!Imperative devient "Faux" au lieu de "False". Le système affiche alors le message d'erreur: "Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en tant que nom de champ ou expression correcte.
Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en "Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas sur une chaine de caractère pour tester la valeur d'un champ Booléen et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci: SELECT * FROM Table1 WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle version d'Access, sur n'importe quelle plateforme et quelle que soit la langue.
A adapter à ton exemple bien sur, mais l'idée est la.
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)" mais n'avais pas fait le lien avec le contexte string de la construction de la requête.
Merci 1000x pour ton aide!
Cordialement
"jean-marc" wrote:
"Yabadabadoo" wrote in message news: > Hello, > > Je développe une application sur une version anglaisse de MSAccess 2003. > Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un > paramètre de type boolean: > > SQLtext = "SELECT * FROM [some table]" > SQLtext = SQLtext & " WHERE ....." > SQLtext = SQLtext & " AND Imperative = " & rs!Imperative > > L'application fonctionne parfaitement correctement. > Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version > française de access ACCESS que la valeur de rs!Imperative devient "Faux" > au > lieu de "False". Le système affiche alors le message d'erreur: > "Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en > tant que nom de champ ou expression correcte. > > Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en > "Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas sur une chaine de caractère pour tester la valeur d'un champ Booléen et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci: SELECT * FROM Table1 WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle version d'Access, sur n'importe quelle plateforme et quelle que soit la langue.
A adapter à ton exemple bien sur, mais l'idée est la.
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)"
mais n'avais pas fait le lien avec le contexte string de la construction de
la requête.
Merci 1000x pour ton aide!
Cordialement
"jean-marc" wrote:
"Yabadabadoo" <Yabadabadoo@discussions.microsoft.com> wrote in message
news:2C85BE88-3258-4334-B228-53BD000FBB9C@microsoft.com...
> Hello,
>
> Je développe une application sur une version anglaisse de MSAccess 2003.
> Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un
> paramètre de type boolean:
>
> SQLtext = "SELECT * FROM [some table]"
> SQLtext = SQLtext & " WHERE ....."
> SQLtext = SQLtext & " AND Imperative = " & rs!Imperative
>
> L'application fonctionne parfaitement correctement.
> Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version
> française de access ACCESS que la valeur de rs!Imperative devient "Faux"
> au
> lieu de "False". Le système affiche alors le message d'erreur:
> "Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en
> tant que nom de champ ou expression correcte.
>
> Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en
> "Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas
sur une chaine de caractère pour tester la valeur d'un champ Booléen
et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci:
SELECT *
FROM Table1
WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de
la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle
version d'Access, sur n'importe quelle plateforme et quelle que soit la
langue.
A adapter à ton exemple bien sur, mais l'idée est la.
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)" mais n'avais pas fait le lien avec le contexte string de la construction de la requête.
Merci 1000x pour ton aide!
Cordialement
"jean-marc" wrote:
"Yabadabadoo" wrote in message news: > Hello, > > Je développe une application sur une version anglaisse de MSAccess 2003. > Dans celle-ci je construis à l'aide de VB des requêtes SQL contenant un > paramètre de type boolean: > > SQLtext = "SELECT * FROM [some table]" > SQLtext = SQLtext & " WHERE ....." > SQLtext = SQLtext & " AND Imperative = " & rs!Imperative > > L'application fonctionne parfaitement correctement. > Ce n'est que lorsque celli-ci est chargée sur un PC ayant une version > française de access ACCESS que la valeur de rs!Imperative devient "Faux" > au > lieu de "False". Le système affiche alors le message d'erreur: > "Le moteur de la base de données Microsoft Jet ne reconnaît pas "Faux" en > tant que nom de champ ou expression correcte. > > Existe-t-il un moyen global afin d'éviter que VB ne "traduise" False en > "Faux"?
Hello,
Non, mais il y a moyen d'écrire du SQL propre qui ne se base pas sur une chaine de caractère pour tester la valeur d'un champ Booléen et qui utilise les booléens pour ce qu'ils sont.
On écrit par exemple ceci: SELECT * FROM Table1 WHERE CBool(isWhatever)=True
La fonction CBool() convertit la valeur Booléenne du Champ indépendamment de la représentation textuelle de la valeur de vérité.
Le code écrit précédemment fonctionne identiquement sur n'importe quelle version d'Access, sur n'importe quelle plateforme et quelle que soit la langue.
A adapter à ton exemple bien sur, mais l'idée est la.
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)" mais n'avais pas fait le lien avec le contexte string de la construction de la requête.
"Yabadabadoo" <Yabadabadoo@discussions.microsoft.com> wrote in message
news:28A177B3-BFB4-4105-9D68-387E79A7E632@microsoft.com...
Hello,
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)"
mais n'avais pas fait le lien avec le contexte string de la construction
de
la requête.
J'avais bien eu le réflexe d'essayer "WHERE whatever = " & val(variable)" mais n'avais pas fait le lien avec le contexte string de la construction de la requête.
