salut à tous,
 
voici ma requête qui foire, Access me retourne des jolies erreurs (voir ci-dessous) :
 
UPDATE Dossiers  
SET Dossiers.NumAR =
     (SELECT NumP  
      FROM Parametres  
      WHERE CodeParametre = 'NUMAR')  // retourne 631
FROM (SELECT d.NumDossier  
      FROM Dossiers d, Clients c  
      WHERE d.CodeClient = c.CodeClient  
      AND d.EditionAR <> 0  
      AND ISNULL(d.NumAR,0) = 0) AR   // retourne une table d'environ 200 enregistrements avec le champ NumDossier
WHERE Dossiers.NumDossier = AR.NumDossier
 
J'ai testé les 2 sous-requêtes séparément, aucun problème.
 
Voici les jolis messages retournés :
 
Une fenêtre d'erreur ODBC, en premier (l'erreur ne se situe pas là, c'est parfaitement configuré)
 
Ensuite, une deuxième fenêtre :

 
Comme il est dit dans le message, on a plusieurs valeurs retournées dans la table AR, mais c'est obligé....
 
Vous avez une ch'tite solution ?!?
Merci
@+

Je sais pas si c'est moi, mais je ne comprends pas la structure de ta requète :
Pour moi, un UPDATE c'est de la forme :  
UPDATE Table
SET Affectations
WHERE Condition
 
Dans la tienne, je vois :
UPDATE Table
SET Affectation
FROM ? ? ? ?
WHERE Condition
 
C'est quoi ce FROM ?

Dac avec Mara's dad

juste un ptit coucou de compassion
 
Car moi aussi j'ai galéré pdt plus d deux semaines sur une requete (un select enplus )
 
Et j'ai posté sur le forum ki ma bie aidé.. MERCI a tous ceux ki mont répondu
 
P.S:  Met ton (select .. ) AR dans ton premier select (dans le from) et la condition Dossiers.NumDossier = AR.NumDossier dans le where du premier select aussi... ca devrai marcher. enfin jespere

[edit]--Message édité par wouatouwouatou--[/edit]

wouatouwouatou > merci je vais essayer....
 
Mara's Dad > j'ai regardé dans l'aide de SQL Server 2000, mais j'ai pas tout compris : en gros, c'est pour accéder à des informations dans des tables et lui donner comme critère (à la requête)

Oups. dsl mais javais pas bien regardé ton update
Essaie ca.. j'suis pas sur ke ca fonctionne mais ca devrai etre mieux D
 

[edit]--Message édité par wouatouwouatou--[/edit]

 
Ce que je ne comprends pas dans ta requête, c'est pourquoi tu as une sous-requête dans la partie FROM.
 
Franchement, j'ai jamais vu ça...
 
Classiquement, j'ai des update du type :

 
Pour moi, un FROM doit contenir une liste de tables ET CAI TOUT.
 
Maintenant, je ne connais pas Access mais le SQL standard... Access permet-il des trucs aussi tordus?

wouatouwouatou a écrit a écrit : Oups. dsl mais javais pas bien regardé ton update Essaie ca.. j'suis pas sur ke ca fonctionne mais ca devrai etre mieux D   Code : UPDATE Dossiers  SET Dossiers.NumAR = (SELECT NumP FROM Parametres WHERE CodeParametre = 'NUMAR') WHERE Dossiers.NumDossier IN (SELECT d.NumDossier FROM Dossiers d, Clients c WHERE d.CodeClient = c.CodeClient AND d.EditionAR <> 0 AND ISNULL(d.NumAR,0) = 0)

 
Chuis nettement plus d'accord avec ça!!!

Moi zossi !

Haaaaa il nous fait des progrès de géant notre petit waoutou

Je vous rassure, c'est pas moi qui ai pondu une merde pareille, mais ma mission, si je l'accepte (de toute façon je n'ai pas le choix   ), c'est de la faire tourner !!!
 
Voici une nouvelle version de "Requête qui pue v1.2" :
 
UPDATE Dossiers  
SET Dossiers.NumAR =  
     (SELECT NumP
      FROM Parametres
      WHERE CodeParametre = 'NUMAR')
 
WHERE NumDossier IN  
  (SELECT d.NumDossier  
  FROM Dossiers d, Clients c
  WHERE d.CodeClient = c.CodeClient
         AND d.EditionAR <> 0  
         AND ISNULL(d.NumAR,0) = 0)
 
 
Apparemment, c'est la même que toi watouatoutoutoua (au passage merci pour l'intéressement que tu me portes !)
mais ça plante toujours, avec le même message
aaaaarrrrrrrgggghhhh    
 
d'autres idées ?
je cherche, je cherche

je viens de m'apercevoir d'une incohérence qui fait que c'est obligé que ça plante :
 
la sous-requête à l'intérieur du WHERE retourne plus de 200 enregistrements, alors qu'il doit trouver qu'un seul NumDossier
 
 
faut que je résolve cela....

Es-tu certain que  
SELECT NumP FROM Parametres WHERE CodeParametre = 'NUMAR'
ne retourne qu'une seule valeur ?

A bon, alors c'est un SELECT DISTINCT qu'il de te faut, dans le IN...

oui, oui, bien sûr, je l'ai testée à part, elle marche nickel cette requête

Tu ne pourrais pas nous donner la structure des tables et une explication fonctionnelle de la requête???
 
Tip : utilise les balises [ code ] et [ /code ] (sans les espaces) pour écrire le code dans ton message.

La requête en question déclenche des Triggers sur le serveur.
Je viens de faire quelques modifs au niveau du serveur : j'ai supprimé tous ces triggers et je les ai recréés
et là oh MAGIE de l'informatique incompréhensible, ça marche !!!!!! YOUHOUHOHUOUOUOU
 
pourquoi, ça je n'en sais rien...
 
En tout cas, Merci à tous pour votre aide !

 
Pas du tout d'accord avec toi (pour une fois ):
1. C'est du SQL standard
2. C'est vachement utile sur les très grosses requêtes (quand t'as 25 tables à mettre dans ton from, c'est beaucoup plus pratique d'y aller par arborescence, en faisant au préalable par exemple l'arbre d'éxécution de la requête)
3. Par la suite, si la requête rame, ca permet de mettre en place de facon plus rapide un schéma d'indexation des tables, une politique de vues, tables temporaires, etc...
4. L'analyseur SQL de n'importe quel SGBD annalyse de facon similaire les deux syntaxes, donc exactement même plan d'éxécution et même performances

[edit]--Message édité par thegti--[/edit]

Alors je viens d'apprendre quelque chose.
 
Merci  
 
En fait, on n'utilise nulle part ce genre de trucs sur mon projet, alors qu'on a 419 procs stockées à ce jour...

hihihihi... J'ai finalement réussi a fire ma foutu requête moi aussi.. D merci a vous tous
 
'ai utilisé ce genre de truc partout dans ma requete... les select dans les from.. C le bordel mais ca tourne, alors ..
 
P.S: He oui, petit wouatou deviendra grand ... de toute facon je peux plus retrecir au point ou j'en suis D

419 procédures stockées
Une stratégie particulière non ? du genre pas faire de requêtes dans l'appli, faire que des procédures stockées ?

thegti a écrit a écrit : 419 procédures stockées Une stratégie particulière non ? du genre pas faire de requêtes dans l'appli, faire que des procédures stockées ?

 
18 mois de développement, une équipe de 4 à 6 personnes, 150 utilisateurs quotidiens...
 
Et, effectivement, faire appel de préférence aux procédures stockées, nettement plus faciles à maintenir que la partie cliente.
Les tailles varient de 1ko à 66Ko (max autorisé par l'outil de codage SQL sous NT...), pour un total de 3.92Mo de code.

Et dire ke ma requete fait 7ko a elle seule.. pfiou.. kel boulot D