Discussion :

[Samuel Galan]

Salut,

Je présente ici un mystère technique au sujet de SQL Server et Access que je voudrais bien comprendre, histoire de me rassurer. En simplifiant le contexte, disons que je requête une table Noms sur SQL Server à travers une table liée TbeNoms dans Access en appliquant éventuellement un filtre à travers un paramètre du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * From TbeNoms Where (Nom = Param Or Param Is Null)

Tout se déroule bien mais maintenant, si je modifie la requête comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * From TbeNoms Where (Nom = Param Or Param Is Null) = TRUE

Je reçois un erreur “ODBC – L’appel a échoué”

Les deux requêtes sont pourtant parfaitement identiques et valides du point de vue strictement SQL. Que se passe-t-il exactement ? Si vous pouviez éclairer ma lanterne… Merci

[=JBO=]

Bonjour,

Les appels ODBC sont toujours un peu délicats au plan syntaxique, notamment les appels de fonctions.
On ne maîtrise pas toujours très bien "l'endroit" où les expressions sont évaluées:
(a) sur le client dans la moulinette ODBC ?
(b) ou bien sur le serveur ?

Je pense que la deuxième requête pose un problème de cet ordre et le "sous-système" qui implémente ODBC préfère jeter le gant.

Les deux requêtes sont pourtant parfaitement identiques et valides du point de vue strictement SQL.

Je ne connais personne qui code le SQL comme dans ta deuxième requête.

Ne serait-ce pas un faux problème ?

Par ailleurs, tu peux aussi créer une requête SQL direct qui utilise la syntaxe native du SGBD cible, et sans interférence de la part d'ODBC.
_

[Samuel Galan]

Salut =JBO=,

Je sais bien que personne ne code ainsi en SQL, pas même moi-même, mais on a hérité de quelques requêtes de ce genre.

La question est que puisque nous nous adressons à SQL Server à travers des tables liées ODBC, je pensais que les requêtes étaient toujours exécutées du côté client, jamais du côté serveur et dans ce cas, les deux syntaxes devraient être correctes puisque les deux sont comprises par Access quand on attaque des tables Access.

Apparemment, quelque chose est faux dans mon raisonnement

[=JBO=]

Apparemment, quelque chose est faux dans mon raisonnement

Le raisonnement n'est pas en cause, mais c'est plutôt une hypothèse qui n'est pas forcément vérifiée:

La question est que puisque nous nous adressons à SQL Server à travers des tables liées ODBC, je pensais que les requêtes étaient toujours exécutées du côté client, jamais du côté serveur ...

Et voilà !... l'analyseur tente de déléguer au serveur un maximum de travail, comme par exemple filtrer les lignes pour les champs dont la valeur est comparée à des constantes ou à la valeur d'un autre champ de la même table.
Théoriquement, ODBC va faire passer ces conditions au serveur pour une utilisation côté serveur.

A ce stade, il faut que le sous-système ODBC puisse "traduire" correctement la syntaxe SQL avant de l'envoyer au serveur, et c'est là qu'il échoue !

Une idée peut-être...
Utiliser un provider OLEDB à la place de l'ODBC.

Maintenant, si il faut juste vérifier la syntaxe de 10 requêtes, je pense que tu auras plus vite fait de les contrôler et les modifier !

Bon courage.
_

[Samuel Galan]

Salut =JOB=,

Je confirme. Après avoir découvert que je pouvais obtenir un Log des appels ODBC, je peux maintenant affirmer que la requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Select * From TbeNoms Where (Nom = Param Or Param Is Null) = TRUE

est envoyée au serveur sous la forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Select * From TbeNoms Where NOT ((Nom = Param Or Param Is Null) = 0)

Or, SQL Server refuse ce type de syntaxe et signale une erreur sur = 0.

SQL Server trouve donc ridicule la tournure Where (Condition) = 1 et la rejette, même si elle est correcte du point de vue SQL.

Merci

[Zabriskir]

En ce qui concerne les logs des appels ODBC, comment fais-tu pour les obtenir ?

Merci