Problème requête Access 2007

Loul du 63 -  
 Loul du 63 -
Bonjour à tous,

Je suis en train de réaliser une base de donnée access, j'ai réussi à créer mes tables et mes formulaires mais je souhaiterai écrire une requête et là ca coince...

J'ai deux tables et j'aimerai dans un premier temps extraire certaines lignes de ma première tablecommande (celle dont l'etat à pour valeur texte "en attente d'archivage"), pour l'archiver dans une seconde. Je compte créer une autre requête afin de supprimer les lignes archivées.

J'ai utilisé la commande ajout et j'ai modifié la requête SQL et j'ai un problème "le nombre de valeurs de la requête doit coïncider avec le nombre de champs de destination"

Mon code est le suivant:
INSERT INTO [tableArchives](nomchamp1A,nomchamp2A,nomchamp3A)
SELECT tableCommande.[nomchamp1,nomchamp2,nomchamp3]
FROM tableCommande
WHERE tableCommande.Etat_commande=="En attente d'archivage";

pour info ma table commande possède plus de champ que ma table archive mais je ne veut pas tous les copier...( je me moque de copier le champ Etat_commande par exemple)

Merci pour votre aide
Loul
ps: j'ai utilisé la requête ajout car j'ai essayé de faire requête sql directe avec le même code mais il me demande d'importer une base de données ODBC, je comprends pas pourquoi car j'utilise une unique base de données..

7 réponses

Résumé de la discussion

Le problème porte sur l’archivage de lignes de tableCommande vers tableArchives via une requête INSERT INTO lorsque l’État_commande est « En attente d’archivage », et l’erreur indique un décalage entre valeurs et champs de destination.
Les échanges portent sur le fait que le SELECT doit afficher le même nombre de colonnes que le INSERT INTO, avec les noms entre crochets si nécessaire et l’utilisation d’un seul signe égal dans WHERE.
Des échanges mentionnent aussi de compléter le SELECT avec uniquement les colonnes à copier, éviter les colonnes non requises comme État_commande, tester en dehors d’un formulaire et privilégier INSERT INTO plutôt que SELECT INTO.
En cas d’échec persistant, plusieurs lecteurs suggèrent d’ajuster les noms entre crochets et de corriger la syntaxe du WHERE, et de vérifier si le nombre de colonnes de la source excède celui des colonnes archivées.

Généré automatiquement par IA
sur la base des meilleures réponses
  1. Gaunts Messages postés 1390 Statut Membre 116
     
    Salut,

    Heu je vois pas trop de problème ayant un rapport avec ton message d'erreur, mais il me semble que
    WHERE tableCommande.Etat_commande=="En attente d'archivage"; 
    est incorrect, en SQL il ne faut qu'un signe "="
    0
  2. Loul du 63
     
    J'ai peut être trouvé j'ai plus d'erreur quand je tape:

    INSERT INTO [tableArchives](nomchamp1A,nomchamp2A,nomchamp3A)
    SELECT tableCommande.[nomchamp1],[nomchamp2],[nomchamp3]
    FROM tableCommande
    WHERE tableCommande.Etat_commande="En attente d'archivage";

    ça fait des crochets dans tous les sens mais ya plus d'erreurs!!!
    merci Gaunts
    0
  3. Loul du 63
     
    Bon maintenant quand j'associe ma requête à un bouton de formulaire, j'ai l'erreur suivante:
    "Une requête INSERT INTO ne peut pas contenir un champ à plusieurs valeurs"
    Pourtant chaque champs que je veut copier contient au plus 1 unique valeur
    Je ne vois pas d'où viens la faute..
    Merci d'avance
    0
  4. Gaunts Messages postés 1390 Statut Membre 116
     
    Salut, essaye ça:
    INSERT INTO tableArchives ( nomchamp1A, nomchamp2A, nomchamp3A ) 
    SELECT tableCommande.nomchamp1, tableCommande.nomchamp2, tableCommande.nomchamp3 
    FROM tableCommande  
    WHERE tableCommande.Etat_commande = "En attente d'archivage"
    0
  5. Vous n’avez pas trouvé la réponse que vous recherchez ?

    Posez votre question
  6. Loul du 63
     
    Merci pour ton aide,
    j'ai fais ta modification, mais j'ai toujours la même erreur.
    Voilà mon code actuel, tu trouvera peut être l'erreur

    INSERT INTO Archives ( DésignationA, Numéro_de_CommandeA, Nom_aéronefA, DélaiA, Nom_intervenantA, DuréeA, Date_de_finA, LieuA, Date_de_réceptionA, DéfautA )
    SELECT Commande.Désignation, Commande.Numéro_de_Commande, Commande.Nom_aéronef, Commande.Délai, Commande.Nom_intervenant, Commande.Durée, Commande.Date_de_fin, Commande.Lieu, Commande.Date_de_réception, Commande.Défaut
    FROM Commande
    WHERE ((Commande.Etat_commande)="En attente d'archivage");
    0
    1. Gaunts Messages postés 1390 Statut Membre 116
       
      L'erreur n'apparait que si tu lances la requete depuis un formulaire? Si tu la lances directement, aucun problème?
      0
    2. Loul du 63
       
      Non j'exécute d'abord ma requête hors d'un formulaire. Mais même seule elle ne marche pas :-(
      0
    3. Gaunts Messages postés 1390 Statut Membre 116
       
      Hmmmmmmmm question bete ta table de destination existe?
      La requete en mode création (et pas sql) ressemble à quelque chose de correct?
      0
    4. Loul du 63
       
      Oui j'ai créé une table Archives.
      Sinon pour la requête en mode création, je ne m'y connais pas trop.
      C'est un tableau
      La ligne champ renseigne les champs des tables
      La ligne table est tout le temps égale à Commande
      et la ligne "Ajouter à" renseigne les champs associés de la table archives
      et la dernière colonne est champ=Etat_commande; Table=commande; critères="en attente d'archivage"
      Voilà ça ne me parle pas trop mais bon ça semble pas faux.
      Sinon les types de mes champs sont de type texte ou date ça pose pas de pb??
      0
    5. Gaunts Messages postés 1390 Statut Membre 116
       
      Non c'est normal, et si il y avait un probleme de ce coté la l'erreur serait différente..
      Toujours en mode création, passe ta requete en mode "Création de table".
      En l'executant, ça va supprimer et recréer ta table archives avec les bonnes valeurs, puis repasse en mode "Ajout"
      0
  7. mahrouch
     
    essai ceci
    'Pour que les noms des tables et colonnes soient bien encadrés entre crochets
    cmdb.QuotePrefix = "["
    cmdb.QuoteSuffix = "]"
    0
  8. Loul du 63
     
    même 3 ans après merci pour ton aide!
    0