[AccessD] Bang v. Dot

[Bill Benson]

Well Rocky it seems you are liking the code you write and a majority of the
time you yourself will be maintaining it. If the application  should
somehow outlive you, I think it will be harder for others in general to
pick up where you left off.

I don’t do a lot of database programming anymore. When I did, for some
reason I most often was using unbound controls. It was more important for
me to write txtClientName knowing I had a likely field ClientName sitting
populating a text box because of things I wanted to do with a textbox
versus a lstClientName listbox.

There was never a guarantee that txtClientName was actually the name of a
field in the recordsource. Maybe I was taking LastName and combining that
with FirstName from my query. I suppose if I wanted to know for certain
whether txtClientName held a field value vs was the product  of a function
in VBA that generated a string to display (suppose I wanted to give the
user the option of displaying names as First & Last or Last & “,” & First)
adding the fld into the name could be helpful…. But I would NEVER give up
the control type prefixing, I would have txtfldClientName.

On Sat, Aug 7, 2021 at 11:31 AM Rocky Smolin <rockysmolin2 at gmail.com> wrote:

> And I not only use fld as a prefix to name a field in a table, I also add
> something that tells me what table the field is in. So the fields in my
> Purchase Order Header table all begin with fldPOH, the ones in the purchase
> or detail table fldPOD.  For tblClient - fldClient. Makes the code more
> self documenting