Précédent   Forum des professionnels en informatique > Logiciels > Microsoft Office > Access
Access Forum d'entraide sur Microsoft Access. Avant de poster -> La F.A.Q Access
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 26/05/2008, 12h09   #1
Invité de passage
 
Inscription : mai 2008
Messages : 7
Détails du profil
Informations forums :
Inscription : mai 2008
Messages : 7
Points : 2
Points : 2
Par défaut Mystère de requêtes SQL dans un contexte Access-SQLServer

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 :
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 :
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
Samuel Galan est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 27/05/2008, 13h14   #2
En attente de confirmation mail
 
Inscription : février 2005
Messages : 1 731
Détails du profil
Informations personnelles :
Localisation : France

Informations forums :
Inscription : février 2005
Messages : 1 731
Points : 2 010
Points : 2 010
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.

Citation:
Envoyé par Samuel Galan Voir le message
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.
_
=JBO= est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/05/2008, 15h02   #3
Invité de passage
 
Inscription : mai 2008
Messages : 7
Détails du profil
Informations forums :
Inscription : mai 2008
Messages : 7
Points : 2
Points : 2
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
Samuel Galan est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/05/2008, 19h10   #4
En attente de confirmation mail
 
Inscription : février 2005
Messages : 1 731
Détails du profil
Informations personnelles :
Localisation : France

Informations forums :
Inscription : février 2005
Messages : 1 731
Points : 2 010
Points : 2 010
Citation:
Envoyé par Samuel Galan Voir le message
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:
Citation:
Envoyé par Samuel Galan Voir le message
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.
_
=JBO= est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/05/2008, 10h17   #5
Invité de passage
 
Inscription : mai 2008
Messages : 7
Détails du profil
Informations forums :
Inscription : mai 2008
Messages : 7
Points : 2
Points : 2
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 :
 Select * From TbeNoms Where (Nom = Param Or Param Is Null) = TRUE
est envoyée au serveur sous la forme :

Code :
 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
Samuel Galan est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/05/2008, 13h42   #6
Membre actif
 
Inscription : juin 2006
Messages : 161
Détails du profil
Informations forums :
Inscription : juin 2006
Messages : 161
Points : 154
Points : 154
En ce qui concerne les logs des appels ODBC, comment fais-tu pour les obtenir ?

Merci
Zabriskir est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 20h33.


 
 
 
 
Partenaires

Hébergement Web