Advantage for using rs.fields("Field").value Vs rs!Field 2

[steve728]

Is there any advantage to using the full (explicit) reference versus the abbreviated one? One of my friends says yes while another says no.

Steve728

 

[Melagan]

I asked a similar question not too long ago - this is known as DOT vs. BANG.
Here is a pretty good article:

http://doc.advisor.com/doc/05352

Despite what this article says, I generally use DOT notion (Me.ControlName, for example) for everything. You do not get intellisense with BANG notation (Forms!FormName!ControlName, for example).


~Melagan
______
"It's never too late to become what you might have been.

 

[PHV]

A very old endless debate.
Do a google search for bang vs dot dao vba

 

[TheAceMan1]

How are ya steve728 . . .

Also [blue]rs.fields("Field")[/blue] and [blue]rs("Field")[/blue] can accept a string variable . . .

Dim FName as String

FName = "LastName"

[blue]rs.fields(FName)
rs(FName)[/blue]

See Ya! . . . . . .

Be sure to see FAQ219-2884:

 

[Melagan]

Additionally, I have not seen much BANG notation outside of VBA. I am studying the ASP.NET 2.0 framework right now and everything is DOT notation in the two sourcebooks I'm reading.

With that - if you are interested in an easy transition between platforms, I would get used to using the DOT notation for good practice.

In my opinion, code looks nice and clean with consistant notation - especially when there isn't really any advantage in using BANG over DOT. I mean...really?

~Melagan
______
"It's never too late to become what you might have been.

 

[TheAceMan1]

Howdy Melagan . . .

For the most part I certainly agree. However in 2k there seems do be a problem using dot with recordsets.
The code below fails where shown with the following error:

[blue]Compile error:

Method or data member not found[/blue]

[blue]Private Sub Name_AfterUpdate()
   Dim rst As DAO.Recordset, hld As String
   
   Set rst = Me.RecordsetClone
   hld = rst[COLOR=red yellow].Credits[/color]
   
End Sub[/blue]

The bang fixes it!

See Ya! . . . . . .

Be sure to see FAQ219-2884:

 

[MajP]

AceMan,
I may be wrong, but I do not think that is an error, but normal expected behavior. If "Credits" is an index to the fields collection then
rst.fields("Credits")
should work or
rst!Credits
should work but
rst.Credits
should not work. This behavior is the same with all collections. The only exception that I can think of is a control on a form, but that is due to the fact that when you add a control to a form it adds it to the controls collection as well as making it a property of the form. When you add a field to a recordset it becomes a member of the fields collection but not a property of the recordset. Any thoughts.

 

[TheAceMan1]

Howdy MajP . . .

. . . and as you've shown the [blue]dot[/blue] is not consistent across the board, but does have its place.

See Ya! . . . . . .

Be sure to see FAQ219-2884:

 

[JoeAtWork]

The dot is consistent - it is always followed by a property or method of the object in front of the dot. In the case of controls on a form, VB automatically adds the control as a property of the form.

rst.Credits would get the same error in VB6 as it does in VBA.

The difference appears to be that in dot notation, if the default property is a collection you still need the brackets and quotes, e.g.

rst("Credits")

whereas with bang you can use just the index name

rst!Credits

or if index has spaces, use square brackets

rst![First Name]

 

[TheAceMan1]

[blue]Use the ! and . (dot) operators in expressions[/blue]

You use the ! and . (dot) operators in an [blue]identifier[/blue] to indicate the type of item that immediately follows.

The ! operator indicates that what follows is a [purple]user-defined item[/blue] ([blue]an element of a collection[/blue]). For example, use the ! operator to refer to an open form, an open report, or a control on an open form or report.

[tt] Identifier Refers to
************************ *******************************************
Forms![Orders] The open Orders form
Reports![Invoice] The open Invoice report
Forms![Orders]![OrderID] The OrderID control on the open Orders form[/tt]

The . (dot) operator usually indicates that what follows is an [purple]item defined by Microsoft Access[/purple]. For example, use the . (dot) operator to refer to a property of a form, report, or control.

Note You can also use the . (dot) operator to refer to a field value in an SQL statement, a Visual Basic for Applications method, or a collection. For example, the identifier Forms![Orders].Controls refers to the Controls collection of the Orders form. However, because the Controls collection is the default collection for forms and reports, it's usually not necessary to refer to it explicitly.

See Ya! . . . . . .

Be sure to see FAQ219-2884:

 

[JoeAtWork]

The . (dot) operator usually indicates that what follows is an item defined by Microsoft Access. For example, use the . (dot) operator to refer to a property of a form, report, or control.

Not one of Microsoft's more precise statements. If I create a public sub on a form called SayHelloWorld(), that is a method not defined by Microsoft Access.
If I create my own class, then every single property and method is not defined by Microsoft Access.

Suffice it to say that both dot and bang notation are consistent in their behaviours.

 

[TheAceMan1]

JoeAtWork . . .

This simply a subject that has no end!

You take care . . . [blue]ya hear![/blue]

See Ya! . . . . . .

Be sure to see FAQ219-2884: