Points d'Exclamation dans un SQL de requête

eh Bien, vous apprenez quelque chose de nouveau chaque jour!

j'avais d'abord prévu d'expliquer que si vous aviez dit que la référence était [formulaires]![FETT de la Liste]![Recherche FETT], il serait alors facile d'expliquer, comme une référence à la commande [Recherche FETT] sur le formulaire [liste FETT]. Mais sans une collection de parent (les deux rapports de formes), il ne ressemble pas à une référence valide dans n'importe quel contexte dans une déclaration SQL.

Mais ensuite j'ai pensé à le tester, et découvert (à ma grande surprise) que cette déclaration SQL est traitée comme valide sous une forme D'accès:

  SELECT [tblCustomer]![LastName] AS LastName 
  FROM tblCustomer;

Dans l'Accès, c'est-à 100% équivalent à cette instruction SQL:

  SELECT tblCustomer.LastName 
  FROM tblCustomer;

... donc je ne comprends pas pourquoi quelqu'un l'écrirait, sauf s'ils ont oublié le contexte (ou ne l'ont jamais compris en premier lieu). C'est peut-être un cas d'aliasing qui a mal tourné, mais ce n'est pas ce que je considère comme une bonne forme.

maintenant, la longue réponse à la question générale de ! (bang) vs. (dot):

Dans en général, dans Access, l'opérateur Bang délimite la collection par défaut d'un objet et de ses éléments. L'opérateur dot délimite un objet et ses méthodes, propriétés et membres.

C'est pour Accès, et s'applique aux objets D'accès et au modèle d'objet pour L'accès.

mais vous utilisez aussi SQL dans Access, et donc vous avez aussi TableName.Nom de champ dans SQL, où l'opérateur de point sépare un élément dans une collection par défaut. TableName.Nom de champ pourrait être considéré comme étant le diminutif de TableName.Fields ("FieldName"), comme vous le trouvez avec les formulaires!MyForm!MyControl étant l'équivalent des formes!MyForm.Contrôles ("MyControl"). Mais cette règle ne s'applique pas dans SQL -- TableName.Fields ("FieldName") n'est pas valide SQL, seulement TableName.FieldName est.

ainsi, vous devez garder en ligne Le paradigme qui contrôle l'espace de noms dans lequel vous travaillez, c'est-à-dire si C'est un espace de noms D'accès ou un espace de noms SQL.

Formulaires!MyForm est aussi équivalent à Forme.Point ("MyForm"), de sorte que la forme ultra-long serait des formulaires.Les Éléments("MyForm").Contrôles ("MyControl"). Notez que l'opérateur bang est un raccourci pour la version plus longue avec l'opérateur dot, de sorte que l'opérateur bang est très souvent utilisé de préférence à l'opérateur dot. Notez aussi que la forme plus longue finit par être utilisée lorsque vous devez vous référer à un élément dont le nom est stocké dans une variable, ce qui n'est pas possible avec l'opérateur bang:

  Dim strForm As String

  strForm = "MyForm"
  ' This is OK
  Debug.Print Forms(strForm).Controls.Count
  ' This is not
  Debug.Print Forms!strForm.Controls.Count

aussi, en code VBA, Microsoft a des choses fabriquées pour brouiller cette distinction dans les formes et les rapports, où il était que moi!MyFavoriteControl était légal comme une référence de contrôle, et Moi.MyFavoriteControl n'aurait été légal qu'en référence à une propriété personnalisée (ou une variable au niveau du module, qui serait membre de l'objet). Vous pourriez également nommer imprudemment une fonction ou un sous - "MyFavoriteControl" et il pourrait être fait référence à avec l'opérateur de point.

mais avec L'introduction de VBA, MS introduit implicitement - créé (et maintenu) les enveloppements de propriété cachés autour de tous les contrôles afin que vous puissiez utiliser l'opérateur de point. Ceci a eu un énorme avantage, et c'est la vérification du temps de compilation des références de contrôle. C'est, si vous tapez Moi.MyFavoriteControl et il n'y a pas de contrôle par ce nom et aucun autre membre d'aucune sorte avec ce nom dans l'espace de nom du formulaire/rapport, alors vous obtiendriez une erreur de compilation (en effet, vous seriez informé de l'erreur dès que vous avez quitté la ligne de code où vous fait l'erreur). Donc, si vous avez eu ce code:

  Debug.Print Me.Control1

... et vous avez renommé Control1 pour être MyControl, vous obtiendriez une erreur la prochaine fois que vous compilez le code.

quel pourrait être l'inconvénient de la vérification de la compilation? Eh bien, plusieurs choses:

1. le code devient plus difficile à comprendre à vue pour le programmeur. Dans le passé, moi!Référence désigne un élément de la collection par défaut d'un formulaire/rapport (qui est une union des champs et des contrôles collection.) Mais Moi.La référence peut être un contrôle ou un champ ou une propriété personnalisée ou une variable au niveau du module public ou une sous-/Fonction Publique ou, ou, ou, ou... Donc, il sacrifie la compréhensibilité immédiate du code.

2. vous dépendez du comportement implicite de VBA et de sa compilation. Alors que c'est généralement une chose correcte à faire (en particulier si vous prenez bien soin de votre code), VBA compilation est très complexe et sujette à la corruption. Au fil des ans, développeurs expérimentés ont signalé que l'utilisation de l'opérateur point rend le code plus sujette à la corruption, car elle ajoute une autre couche de code caché qui peuvent être synchronisés avec les parties de l'application que vous modifier explicitement.

3. depuis que vous ne pouvez pas contrôler ces enveloppements implicites de propriété, quand ils vont mal, vous devez recréer votre objet module-bearing à partir de zéro (habituellement SaveAsText est suffisant pour effacer la corruption sans perdre quoi que ce soit).

ainsi, de nombreux développeurs expérimentés (dont moi-même) n'utilisent pas l'opérateur dot pour contrôler les formulaires/rapports.

ce n'est pas un tel sacrifice que certains pourraient penser si vous utilisez un ensemble standard de conventions de nommage. Par exemple, avec les contrôles liés sur les formulaires, un laissez-les utiliser les noms par défaut (c.-à-d., le nom du champ auquel le contrôle est lié). Si Je ne me réfère pas au contrôle en code, je ne change jamais son nom. Mais la première fois que je référez-vous à lui dans le code, je change son nom de sorte que le nom de contrôle est distinct du nom du champ auquel il est lié (cette désambiguïsation est cruciale dans certains contextes). Donc, une boîte de texte appelée MyField devient txtMyField au moment où je décide de m'y référer en code. La seule fois où j'ai changé le nom du champ après que le code est écrit, c'est quand j'ai décidé que le champ était mal nommé. Dans ce cas, il est assez facile de faire une recherche/remplacement.

certains soutiennent qu'ils ne peuvent pas abandonner Intellisense, mais il n'est pas vrai que vous l'abandonnez complètement lorsque vous utilisez l'opérateur de bang. Oui, vous abandonnez L'Intellisense "vraiment intelligent", c'est-à-dire la version qui limite la liste Intellisense aux méthodes/propriétés/membres de l'objet sélectionné, mais je n'en ai pas besoin pour cela -- J'ai besoin D'Intellisense pour sauvegarder les frappes, et avec CTRL-SPACEBAR vous obtenez une liste Intellisense complète qui autocomplète tout comme L'Intellisense spécifique au contexte, et peut alors court-circuiter le taper.

un autre domaine de la confusion point / bang est celui des recordsets DAO en code VBA, dans lequel vous utilisez l'opérateur point pour le SQL que vous utilisez pour ouvrir votre recordset et l'opérateur bang pour faire référence aux champs dans le recordset résultant:

  Dim rs As DAO.Recordset

  Set rs = CurrentDB.OpenRecordset("SELECT MyTable.MyField FROM MyTable;")
  rs.MoveFirst
  Debug.Print rs!MyField

  rs.Close
  Set rs = Nothing

si vous gardez à l'esprit l'espace de noms dans lequel vous travaillez, ce n'est pas si confus -- le point est utilisé dans la déclaration SQL et le bang dans le code DAO.

Donc, pour résumer:

1. dans SQL, vous utilisez l'opérateur de point pour les champs dans les tables.

2. dans les formulaires et les rapports, vous utilisez l'opérateur bang pour les contrôles et l'opérateur dot pour les propriétés/méthodes (bien que vous pouvez également utiliser l'opérateur dot, mais ce n'est pas nécessairement conseillé).

3. dans le code VBA, les références aux contrôles sur les formulaires et les rapports peuvent utiliser un point ou un bang, bien que le point puisse être sujet à une possible corruption de code.

4. en SQL, vous pouvez voir l'opérateur bang utilisé, mais seulement s'il y a une référence à un contrôle sur un formulaire D'accès ou de rapport, du formulaire "Form!FormName!Nomchamp" ou "Rapport de!ReportName!Nomchamp".

5. dans le code VBA travaillant avec DAO recordsets, vous pouvez voir à la fois le point et l'opérateur bang, le premier dans la définition du SQL qui est utilisé pour ouvrir le recordset, et le second pour se référer aux champs dans le recordset résultant une fois qu'il est ouvert.

Est compliqué assez pour vous?

je pense que le point d'esclamation n'est qu'un séparateur conventionnel.

dans Oracle PL / SQL vous utilisez dot:

[liste FETT].[Fett Search]

Tout les autres indices?!