Formulaire d'accès - erreur de Syntaxe (opérateur absent) dans l'expression de la requête

Je reçois une erreur de syntaxe dans un formulaire que j'ai créé sur une requête. J'ai créé un formulaire pour restreindre l'accès à l'évolution des dossiers. Tout en essayant de définir des filtres sur la forme, je reçois des erreurs de syntaxe pour tous les attributs j'essaie de filtrer. Je crois que cela a quelque chose à voir avec le manque de () autour de la jointure interne au sein du code de requête, mais ce qui est bizarre pour moi est que je peux filtrer la requête sans problème. Ci-dessous le code de requête:

SELECT CUSTOMER.[Product Number], SALESPERSON.[Salesperson Number],
SALESPERSON.[Salesperson Name], SALESPERSON.[Email Address]
FROM SALESPERSON INNER JOIN CUSTOMER ON
SALESPERSON.[Salesperson Number] = CUSTOMER.[Salesperson Number];

Des idées pourquoi seulement la forme que pourrait générer l'erreur de syntaxe, ou de comment résoudre ce problème?

  • Depuis la requête comprend qu'une seule jointure, () ne devrait pas être nécessaire. Ma meilleure supposition est que la requête n'est pas la cause du problème. Il doit être quelque chose en raison de la méthode que vous utilisez pour définir le filtre ou d'un problème avec le filtre expression de chaîne de caractères.
  • Vous pouvez éliminer la requête en testant le SQL dans le concepteur de requêtes.
  • La requête que vous avez posté, semble très bien fonctionner. Je pense que ce que vous avez besoin de partager avec nous, c'est exactement la façon dont vous essayez de filtrer les enregistrements. Veuillez envoyer la syntaxe exacte et l'échantillon.
  • La requête fonctionne très bien, aucun filtre de problèmes du tout. Aussi loin que la façon dont je suis en train de filtre, dans la forme je suis en cliquant sur la flèche de la liste déroulante pour chaque attribut, c'est quand je reçois le message d'erreur. J'ai aussi remarqué aucune donnée n'est répertorié pour les enregistrements dans la liste déroulante une fois qu'il ouvre. J'ai constaté que je peux le filtre en cliquant-droit sur un rempli de cellules bien.
InformationsquelleAutor FGLC0983 | 2014-02-07
  1. 9

    J'ai été en mesure de résoudre rapidement en allant dans la Vue de Conception de la Forme et de mettre des [] autour de tous les noms de champ qui avait des espaces. Je suis maintenant en mesure d'utiliser le construit dans les filtres sans le popup ennuyant sur les problèmes de syntaxe.

    • Ce répondu à ma question.....je vous remercie.
    • Cela a réglé mon problème. Merci pour l'astuce.
    • Pas de. Ce qui est mauvais. Découvrez ma réponse ci-dessous. Prendre les espaces, de profiter de chaque mot, de prendre de l'redondant noms de table, ne pas utilisé des mots clés réservés comme number ou select. Par exemple: Salesperson.Salesperson phone number devient Salesperson.Phone
    InformationsquelleAutor Dedren
  2. 6

    J'ai eu ce même problème.
    Comme Dedren dit, le problème n'est pas la requête, mais la forme de l'objet source de contrôle. Mettre [] autour de chacun des objets de Source de Contrôle. par exemple: Contol Source: [Product number], Control Source: Salesperson.[Salesperson number], etc.

    Makita recomends aller à la table d'origine auquel vous faites référence dans votre requête et renommer le champ afin qu'il n'y a pas d'espaces par exemple: SalesPersonNumber, ProductNumber, etc. Cela permettra de résoudre de nombreux problèmes à l'avenir aussi bien. Bonne Chance!

    • Je ne sais pas pourquoi les gens sont downvoting vous en fait, cela a résolu mon problème merci.
    • Aussi, prenez le SalesPerson partie de et de le modifier Number à ID. Salesperson number devrait être modifiée pour simplement ID
    • Salesperson phone number => PhoneNumber ou Phone
    InformationsquelleAutor msllarson2
  3. 2

    Essayez de faire les noms de champ juridique en supprimant les espaces. C'est un long shot, mais il a effectivement aidé moi avant.

    • Essayé dans la requête, mais pas de chance.
    • Cela a fonctionné pour moi, j'ai remplacé les espaces par des caractères de soulignement
    • Oui. C'. Ne remplacez pas avec _, cependant. Capitaliser chaque mot. phone number devient PhoneNumber ou tout simplement Phone
    InformationsquelleAutor Makita
  4. 0

    J'ai fait le résoudre rapidement en allant dans "mode création" de la Table principale de la même Forme et la mise souligner (_) entre les noms de champ qui avait des espaces. Je suis maintenant en mesure d'utiliser le construit dans les filtres sans le popup ennuyant sur les problèmes de syntaxe.

    • Il suffit de prendre l' _ et de tirer profit de chaque mot. Les noms courts, ne pas répéter le nom de la table. Plus c'est court, mieux c'est. Nous ne voulons pas faire du mal à vos pauvres doigts tapant des choses, encore et encore.
    InformationsquelleAutor Kasra
  5. 0

    Mettre [] autour de tous les noms de champ qui avait des espaces (comme Dreden dit) et enregistrez votre requête, le fermer et le rouvrir.

    À l'aide de l'Accès 2016, j'avais toujours le message d'erreur sur les nouvelles requêtes après j'ai ajouté [] autour de tous les noms de champ... jusqu'à ce que la Requête a été enregistrée.

    Une fois que la Requête est enregistrée (et visible dans la Liste d'Objets), fermé et rouvert, le message d'erreur disparaît. Ce qui semble être un bug de l'Accès.

    • Pas de. Ne mettez pas de [] autour d'elle. Vous allez faire ça partout. Sortir des espaces, des caractères spéciaux, les noms de table(comme Salesperson.Salesperson number), ne pas utiliser de mots clés réservés, et vous n'aurez pas de mettre [] autour de tout.
    InformationsquelleAutor Chris H.
  6. 0

    Non, non, non.

    Ces réponses sont toutes dans l'erreur. Il est fondamental de l'absence de connaissances dans votre cerveau que je vais remédier à droite maintenant.

    Votre problème majeur ici est votre schéma de nommage. C'est verbeux, contient des caractères indésirables, et c'est horriblement incompatible.

    Première: Une table qui s'appelle Salesperson n'a pas besoin d'avoir chaque champ de la table appelée Salesperson.Salesperson number, Salesperson.Salesperson email. Vous êtes déjà dans la table Salesperson. Tout dans ce tableau se rapporte à Salesperson. Vous n'avez pas à garder le dire.

    Au lieu d'utiliser ID, Email. N'utilisez pas de Number parce que c'est probablement un mot réservé. Avez-vous vraiment s'efforcer de type [] autour de chaque nom de champ pour la durée de vie de votre base de données?

    Les clés primaires sur une table appelée Student peut être ID ou StudentID mais cohérente. Les clés étrangères doivent seulement être nommé par le tableau des points, suivie par ID. Par exemple: Student.ID et Appointment.StudentID. ID est toujours en majuscule. Je n'ai pas de soins si votre IDE vous dit de ne pas parce que partout mais votre IDE sera ID. Même l'Accès aime ID.

    Deuxième: le Nom de tous vos champs sans espaces ni de caractères spéciaux et de le garder aussi courte que possible, et si elles entrent en conflit avec un mot réservé, trouvez un autre mot.

    Au lieu de: phone number utilisation PhoneNumber ou encore mieux, tout simplement, Phone. Si vous choisissez what time user made the withdrawal, vous allez avoir à taper dans tous les temps.

    Troisième: Et c'est le plus important un: Toujours être cohérent dans tout ce schéma de nommage que vous choisissez. Vous devriez être en mesure de dire, "j'ai besoin le code postal de la table; son nom va être Codepostal." Vous devriez savoir que, sans même avoir à le chercher parce que vous étiez cohérent dans votre convention de nommage.

    Récapitulatif: Laconique, pas verbeux. Garder les noms courts, avec un pas d'espaces, de ne pas répéter le nom de la table, ne pas utiliser des mots réservés, et de tirer profit de chaque mot. Par-dessus tout, être cohérent.

    J'espère que vous prenez mes conseils. C'est la bonne façon de le faire. Ma réponse est la bonne. Vous devez être extrêmement pointilleux avec votre schéma de nommage au point de l'obsession absolue pour le reste de votre vie sur cette planète.

    REMARQUE:Vous devez modifier le nom du champ dans la vue de la conception de la table et dans la requête.

    InformationsquelleAutor Bluebaron
  7. 0

    Supplémentaires ( ) les parenthèses peuvent créer des problèmes dans d'autre si le débit. Cela crée aussi une erreur de Syntaxe (opérateur absent) dans l'expression de la requête.

    InformationsquelleAutor Robin
  8. 0

    J'ai eu ce sur une forme où la Source est dynamique.

    Sql était bien, la réponse est pour intercepter l'erreur!

    Private Sub Form_Error(DataErr As Integer, Response As Integer)
'    Debug.Print DataErr

    If DataErr = 3075 Then
        Response = acDataErrContinue
    End If

End Sub
    InformationsquelleAutor Reuben Molloy