Comment dois-je effectuer la mise à jour de la requête avec une sous-requête dans Access?

Je veux le port de cette requête SQL qui fonctionne très bien sur SQL Server, MySQL et Oracle, pour une base de données Access. Comment dois-je faire? pour l'instant il me demande une Company_ID pour une raison quelconque.

Modifier: j'ai été d'obtenir l'invite parce que j'ai oublié de créer d'abord les Company_ID colonne dans VendorRegKeys. Maintenant j'obtiens l'erreur "l'Opération doit utiliser une requête de mise à jour".

UPDATE VendorRegKeys
   SET Company_ID = (SELECT Users.Company_ID
                     FROM Users
                     WHERE Users.User_ID = VendorRegKeys.CreatedBy_ID)

Mise à jour: j'ai trouvé que c'était basé sur JuniorFlip's réponse:

UPDATE VendorRegKeys, Users
SET VendorRegKeys.Company_ID = Users.Company_ID
WHERE VendorRegKeys.CreatedBy_ID = Users.User_ID
Merci, cela m'a beaucoup aidé!
Remarque: Si les Utilisateurs est une Requête en opposition à une Table, et, par conséquent, pas être mis à jour, le résultat est "l'Opération doit utiliser une requête de mise à jour".

OriginalL'auteur Kip | 2009-09-03

  1. 12

    Ce pourrait être parce que Company_ID n'est pas un champ existant dans VendorRegKeys OU les Utilisateurs.

    EDIT: 

    UPDATE VendorRegKeys
INNER JOIN Users ON Users.User_ID = VendorRegKeys.CreatedBy_ID
SET VendorRegKeys.Company_ID = Users.Company_ID
    oups, company_ID n'existait pas dans VendorRegKeys. Mais après l'ajout, je reçois maintenant "l'Opération doit utiliser une requête de mise à jour"
    n'ai pas vu que tu avais édité dans une requête qui fonctionne... de l'acceptation de votre réponse, car il fonctionne réellement. merci!

    OriginalL'auteur shahkalpesh

  2. 10

    Droit de réponse: vous ne pouvez pas. L'Accès au Moteur de Base de données simple ne prend pas en charge la vanille SQL-92 sous-requête scalaire de la syntaxe, même dans ses propres ANSI-92 Mode d'interrogation.

    Vous êtes contraint d'utiliser son propre syntaxe qui n'applique pas le scalaire exigence est dangereux et va chercher une valeur arbitrairement et silencieuse**. De plus, au-delà de simples constructions qu'il ne fonctionne pas à tous, notamment lorsque votre sous-requête (si vous avez été autorisé à utiliser l'une en premier lieu) utilise une fonction de jeu (MAX, SUM, etc) -- voir cet article pour certains vraiment insatisfaisant des solutions de contournement.

    Désolé d'être négatif, mais c'est vraiment de base de la syntaxe et je ne comprends pas pourquoi l'équipe d'Accès n'ai pas eu l'occasion de le fixer encore. Il est le numéro un incontesté de la raison pourquoi je ne peux pas prendre la base de données Access moteur au sérieux plus.

    Pour démontrer le comportement à risque de l'Accès exclusif UPDATE..JOIN..Set syntaxe

    CREATE TABLE Users
( 
  User_ID CHAR( 3 ) NOT NULL,
  Company_ID CHAR( 4 ) NOT NULL,
  UNIQUE ( Company_ID, User_ID ) );

CREATE TABLE VendorRegKeys
  CreatedBy_ID CHAR( 3 ) NOT NULL UNIQUE,
  Company_ID CHAR( 4 ) );

INSERT INTO Users VALUES ( 'Kip', 'MSFT' );
INSERT INTO Users VALUES ( 'Kip', 'AAPL' );

INSERT INTO VendorRegKeys VALUES ( 'Kip', NULL );

UPDATE VendorRegKeys
INNER JOIN Users ON Users.User_ID = VendorRegKeys.CreatedBy_ID
SET VendorRegKeys.Company_ID = Users.Company_ID;

    Lors de l'exécution de la mise à jour de la déclaration dans l'Accès, l'INTERFACE utilisateur avertit que nous

    Vous êtes sur le point de mettre à jour 2 ligne(s).

    malgré le fait il n'y a qu'une seule ligne dans le VendorRegKeys table!

    Ce qui se passe dans la pratique est que l'une des valeurs qui nous sera utilisé pour mettre à jour la colonne dans cette seule ligne, sans un moyen fiable de prédire qui il sera.

    Avec le Standard SQL de la sous-requête scalaire de la syntaxe, vous obtenez un message d'erreur et l'instruction de ne pas exécuter, ce qui est sans doute la fonctionnalité désirée (Standard SQL MERGE syntaxe se comporte de cette façon).

    merci pour toutes ces infos. je n'ai jamais pris de l'accès au sérieux, mais la direction affirme que nous avons à l'appui de toute façon. :-/ Au moins dans ce cas, il existe une autre syntaxe qui fonctionne.
    +1 pour "mais la direction a dit..."

    OriginalL'auteur onedaywhen

  3. 8

    vous pouvez essayer ce un

    update a
set a.company_id = b.company_id
from vendorRegkeys a, users b
where a.createdby_id = b.user_id
    hmm.. ça donne une erreur: erreur de Syntaxe (opérateur absent) dans l'expression de requête 'b.company_id de vendorRegkeys un"
    je l'ai eu à travailler avec une version légèrement modifiée de ce, mis à jour en question. merci!

    OriginalL'auteur JuniorFlip