Variable Declaration in MS Access 2013 VBA

[msaccessdev]

Hi There,

Hope all doing good.



what do we mean by declaring few variables like below in the VBA window.

1) I am confused why do we declare variables with $ or & symbols ? does it really have specific property or meaning ?
Option Compare Database


Private ptoC$, tempRS As Recordset, dbTest$, allNEW As Boolean



2) How can we leave the second declaration with out telling it "Integer" or "String" etc... and MS Access accepts it very well and executing fine ?
Private empTeam&, exeRack&, eType$, msgType$


please guide me.

Thanks,
MS access

[ranman256]

Stop using antiquated variable declarations with $ or &. (from the 70s)

Spell it out...
dbTest as string
ptoC as currency

[ItsMe]

Unlike other programming languages you need to explicitly declare your variables in VBA, each variable. So including several variables in a single line will not carry the first data type to the subsequent variables.

Dim sMyString as String, sOtherString, sLastString

will not work

sOtherString and sLastString will default to type Variant unless you explicitly declare the variable

Dim sMyString as String, sOtherString as String, sLastString as String

or
Dim sMyString as String
Dim sOtherString as String
Dim sLastString as String

[msaccessdev]

Hi Thanks for your suggestion,

but, my questions was

1) unlike the normal declaration of the variables, declaring them with extra characters like & or $ makes any difference in the code ?

ItsMe:
2) since you said declaring like the "Dim sMyString as String, sOtherString, sLastString" wont work. but, i dont have any problem in the code and application is running fine without throwing any errors. my previous team member declared the variables like that before i join around 3 months back in MS Access 2013 and i am trying to edit the code and seen these declarations.

thanks

[June7]

Not explicitly specifying type will work - the variable will default to Variant. Variant allows the variable to hold any kind of data. Variants use more memory.

I have seen the $ used but never used myself. As ranman stated this just might be old but still valid syntax.

Just as the + character will work to concatenate text because it is carry over from old BASIC but & is preferred concatenation operator in Access and VBA.

[ItsMe]

...
ItsMe:
2) since you said declaring like the "Dim sMyString as String, sOtherString, sLastString" wont work. but, i dont have any problem in the code and application is running fine without throwing any errors. my previous team member declared the variables like that before i join around 3 months back in MS Access 2013 and i am trying to edit the code and seen these declarations.

It will default to Variant type, which will not truncate most of the other types. So it may work but may not work the way you intended when writing the declaration.

As far as using the special characters, I see it on occasion and it seems to still work. I know I have a couple modules that still have it, where I did not bother to change it. If your IDE compiles it and you, along with others, understand it, I suppose there is not any harm in it. I know I do a double take when I see it and ask myself what the heck.

[msaccessdev]

Great, thank you all for your insights and suggestions.

its really helpful.

thank you.

[Missinglinq]

In olden days, before mice and WIFI and Windows, the Variables in BASIC could be declared by simply adding a Special Character to the end of the name; that was all you needed to do to declare a Variable. The $ at the end of

MyVariable$

told BASIC that MyVariable was a String Variable.

You'll see it in really old, legacy code (I've got a bunch of that, but it's on floppy discs, and I have no floppy discs drives) but it won't work in Access, without being Dim'd.

It is generally considered very bad practice to use any Special Characters, with the exception of the Underline, in the name of anything in Access VBA. You might get away with for a while, maybe even a long while, but sooner or later it'll jump up and bite you where you won't like to be bitten! And tracking down the problem, when it occurs, can be a real bear!

Linq ;0)>