how to avoid hard-coding of database field names?

[Eych]

I have several functions that retrieve information from databases based
on the fieldname passed in (e.g. GetValue(dbUsers, userID, "Fax"))

what is the best way to not hard-code field names?

Something like this would be nice:

Enum UserTable
Fax = "Fax"
Phone = "Phone"
End Enum

where I can use GetValue(dbUsers, userID, UserTable.Fax) and just
modify the Enum if I change field names?

Thanks...
Eych

[Eych]

created a new module, moduleTables, that has:

Public class Table1
Public const Fax = "Fax"
Public const Phone = "Phone"
....
End Class

etc. for other tables.
So, I can call
Dim tmpClass as Table1
GetValue(dbUsers,userID, Table1.Fax)

Is this good coding standards?

[Phill. W]

"Eych" <ey******@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Something like this would be nice:

Enum UserTable
Fax = "Fax"
Phone = "Phone"
End Enum

GetValue( dbUsers, userID, UserTable.Fax )

and just modify the Enum if I change field names?

What you've got /can/ be adapted, something like this :

Enum UserTable
Fax = 0
Phone
End Enum

It doesn't actually matter what the numbers are, but it means you
/can/ use

GetValue( dbUsers, userID, UserTable.Fax )

BUT - your function received the Enum "value" (0, 1, etc. ) but
you need the Enum's "name" ("Phone", "Fax", etc.) and, believe it
or not, we can do that these days!

Function GetValue( ... , ByVal eaField as UserTable )
Return SomethingBasedOn( eaField.ToString() )
End Function

HTH,
Phill W.

[Eych]

that'll work!

thanks!

Eych

[Gerald Hernandez]

"Eych" <ey******@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

created a new module, moduleTables, that has:

Public class Table1
Public const Fax = "Fax"
Public const Phone = "Phone"
...
End Class

etc. for other tables.
So, I can call
Dim tmpClass as Table1
GetValue(dbUsers,userID, Table1.Fax)

Is this good coding standards?

IMHO, this is a far better solution than using the other method proposed
(extracting the name of the enum field itself).
The main reason is flexibility. What if you wanted to change the name of the
field, say change Fax to Fax2. You would still have to do a find and replace
to locate all instances where you explicitly used Table1.Fax to Table1.Fax2.
Plus other possibilities for quirks and confusion.

Now if you created your "enumeration" as a class like you propose, then no
other code changes would be required. It would not matter what the variable
name is, just the value returned. So if you change the "Fax" field name to
"Fax2", then just change: Public const Fax = "Fax" to Public const Fax = "Fax2"

and that's it.

It makes your code easier to maintain, for yourself and anyone else that
might need to.
Say at some point in the future, you wanted the ability to dynamically map
the field names via a config file. Well, if the field name is returned by a
class, all you need to do is alter the class to read the values from the
file. Again, you could leave your other code untouched.

So, personally I would, and have, taken the class route. Now, the other
point of discussion would be the scoping of the class itself. Should it
contain only static methods? Should it be a child class of possibly the
class that handles all the other DB interaction, if any. Etc. That can only
really be answered by considering your overall architecture and such.

Gerald