IP address rather than server name

[BruceM via AccessMonster.com]

Actually, there are a couple of questions here. I will get to the topic in
the subject line shortly, but the first question leads to that one.

I am setting up a database that uses hard-coded values for things such as the
location address. However, the database will be used in other locations, so
I have made a LocationsVariables table. There is a single record, with maybe
8-10 fields. When I need one of the values I use a DLookup:
DLookup("[SomeField]","[tblLocVariables]")
With only one record the DLookup seems efficient enough. I assign it to a
variable within a procedure if necessary to use it several times within a
single procedure. However, I wonder if there is a way to assign the variable
once when the startup form opens. I am reluctant to use a global variable
because of concerns about it being reset by an unhandled error. I use error
handling in all procedures and functions, but still it seems that a global
variable is potentially fragile.

The IP address part of the question is that for some reason the server name
does not always work as part of a path, but the IP address does. I need to
use network paths in some places, but on some computers this has not been
working. I expect it is a configuration problem of some kind, but it seems
it may not be addressed any time soon, if at all. I have found code to
convert server name to IP address. In my tests it works very well. I wonder
if there are potential issues with using the IP address rather than the
server name. If it is OK to convert, the server name would be one of the
LocationVariables, and I would run the IP conversion code using that value.

Again, the question arises whether it is best to store the value once or run
the function each time the IP address is needed. As an alternate approach,
LocationVariables data would be editable by only a few people, but it should
be possible to store the IP address in a table by running the code when the
server name is first entered via the LocationVariables form. Thereafter each
user would run the IP address function when starting the database and compare
it to the table value. If they match, no problem. If not, they could get a
message box advising them to contact somebody or other.

 

[Albert D. Kallal]

However, I wonder if there is a way to assign the variable

once when the startup form opens. I am reluctant to use a global variable
because of concerns about it being reset by an unhandled error. I use
error
handling in all procedures and functions, but still it seems that a global
variable is potentially fragile.

Some people use a form that is not visible, and assign values to text boxes
so they don't re-set.

However, why not distribute a mde? A mde forces your code to be compiled,
results in a smaller application, runs faster, and also ANY un-handled
NEVER re-sets global vars. So, a mde is strongly recommend for your
production software. (this assumes your application is split).

I used mde's for years since you don't need error handling (and in the
runtime un-handled errors don't shut down the application). The result
is a FAR more robust application when you do this.

The IP address part of the question is that for some reason the server
name
does not always work as part of a path, but the IP address does.

Yes, I seen the above also. It tends to be some wins resolution issue
and thus using IP is a ok workaround.

I
wonder
if there are potential issues with using the IP address rather than the
server name.

Not really. I mean the server name stuff SHOULD work. And, if they
introduce a new server and the IP address changes, then you have to
re-link to the new server IP address. The other way around would
allow a new box to be introduced with the OLD server name, and
you would in theory not have to re-link. However, at the end of the day, I
really don't see a downside to using a IP address (the exception being that
if your IT department knew what they were doing, then the server name SHOULD
work).

Again, the question arises whether it is best to store the value once or
run
the function each time the IP address is needed.

The IP issue here is moot. If you need to change the \\servername, then you
need to change the IP address.

If you don't ever have to change the servername, then you don't have to
change the IP address. So, this is question is NOT related to using
\\servername or IP address. it is a legitimate question, but NOT related to
ip vs server name.

but it
should
be possible to store the IP address in a table by running the code when
the
server name is first entered via the LocationVariables form. Thereafter
each
user would run the IP address function when starting the database and
compare
it to the table value. If they match, no problem. If not, they could get
a
message box advising them to contact somebody or other.

Well, this issue is how does your startup code manage the issue of linking
the tables from the from end to the back end. In other words, most everyone
has cobbled together some type of re-linking code that they use when
distributing their software. Again, this issue does not change if your using
an IP address or a server name.

In the case where I have physical use of the local network, then I link my
mdb to the back end (using unc pathnames, or in your case, an IP address).
You then create the mde, and then distribute that mde to each desktop. In
this case, we really don't need any startup code for re-linking.

However, for my many customers that I never seen, nor can I be on location,
then I create that mde, but it currently linked to my back end, and on their
networks, the data file location for the back is different. So, I have some
startup code that checks the current linked location, and the one that was
last used during linking (it placed in a text file in the program directory
where the mde is placed). So, during startup, if the current back end link
is wrong, then the re-link occurs. And, I should well note that SOME of my
clients that have the SAME problem as you (the server name craps out and
does not work they in fact link to the back end database file via an IP
address. However, my re-link code happy accepts both an IP address or a
server name...and I can't think any real problem that exists using IP or
server name (the exception being that the network and support people not
competent).

 

[Klatuu]

I have never used IP addresses in Access, so I can't address that issue, but
I do have a suggestion on storing those values once.

You can use a Static Function in a standard module to store and retrieve the
value. It will not be affected by an unhandled error.

Here is an example:

Static Function GetSSN(Optional ByVal varNewSSN As Variant) As String
Dim varSSN As Variant

If Not IsMissing(varNewSSN) Then
varSSN = varNewSSN
End If
GetSSN = varSSN
End Function

When you pass a value to the function, it stores it in the varialbe varSSN.
If you call the function with no argument, it will return the stored value.
So in your startup form, you might do something like this:

GetSSN(Dlookup("[enteredon]","[tblClient]","[MainName] = ""Jones"" AND
[FirstName] = ""Martha"""))

When you need to retrieve it, it is just a function call:

strEnterDate = GetSSN

--
Dave Hargis, Microsoft Access MVP

Actually, there are a couple of questions here. I will get to the topic in
the subject line shortly, but the first question leads to that one.

I am setting up a database that uses hard-coded values for things such as the
location address. However, the database will be used in other locations, so
I have made a LocationsVariables table. There is a single record, with maybe
8-10 fields. When I need one of the values I use a DLookup:
DLookup("[SomeField]","[tblLocVariables]")
With only one record the DLookup seems efficient enough. I assign it to a
variable within a procedure if necessary to use it several times within a
single procedure. However, I wonder if there is a way to assign the variable
once when the startup form opens. I am reluctant to use a global variable
because of concerns about it being reset by an unhandled error. I use error
handling in all procedures and functions, but still it seems that a global
variable is potentially fragile.

The IP address part of the question is that for some reason the server name
does not always work as part of a path, but the IP address does. I need to
use network paths in some places, but on some computers this has not been
working. I expect it is a configuration problem of some kind, but it seems
it may not be addressed any time soon, if at all. I have found code to
convert server name to IP address. In my tests it works very well. I wonder
if there are potential issues with using the IP address rather than the
server name. If it is OK to convert, the server name would be one of the
LocationVariables, and I would run the IP conversion code using that value.

Again, the question arises whether it is best to store the value once or run
the function each time the IP address is needed. As an alternate approach,
LocationVariables data would be editable by only a few people, but it should
be possible to store the IP address in a table by running the code when the
server name is first entered via the LocationVariables form. Thereafter each
user would run the IP address function when starting the database and compare
it to the table value. If they match, no problem. If not, they could get a
message box advising them to contact somebody or other.

 

[David W. Fenton]

I am setting up a database that uses hard-coded values for things
such as the location address. However, the database will be used
in other locations, so I have made a LocationsVariables table.
There is a single record, with maybe 8-10 fields. When I need one
of the values I use a DLookup:
DLookup("[SomeField]","[tblLocVariables]") With only one record
the DLookup seems efficient enough. I assign it to a variable
within a procedure if necessary to use it several times within a
single procedure. However, I wonder if there is a way to assign
the variable once when the startup form opens. I am reluctant to
use a global variable because of concerns about it being reset by
an unhandled error. I use error handling in all procedures and
functions, but still it seems that a global variable is
potentially fragile.

If the data you are contemplating storing in global variables is
itself stored in a table or any other persistent storage method
(registry, INI file, XML file, etc.) or is available outside Access
(from an API call), it's very easy to create functions that return
the value that are both efficient and self-healing (i.e., will
re-initialize after a code reset). I am strongly against global
variables and this is the kind of function I write all the time:

Public Function GetUser() As String
Static strUser As String

If Len(strUser) = 0 Then
If CurrentUser() = "Admin" Then
strUser = fGetUserName()
Else
strUser = CurrentUser()
End If
End If
GetUser = strUser
End Function

The key is the use of the STATIC variable, which unlike normal
variables, survives the scope of a call to the function. That is,
the first time you call the function, the static variable is
unitialized. Once you've called it, it is initialized and stays that
way until the next code reset.

So, you only look up the information once, stick it in the static
variable, and then, as long as there's not a code reset, the value
is returned from the static variable, instead of looing it up again.

In your situation, you might have something like:

Public Function GetIP() As String
Static strIP As String

If Len(strIP) = 0 Then
strIP = DLookup("Value","tblConfig","[Key]='ServerIP'")
End If
GetIP = strUser
End Function

That assumes you have your data stored in tblConfig, with Key and
Value columns. The first time you call it, the static variable is
uninitialized, so it calls the DLookup() to find the value, and puts
it in the static variable. The next time the function is called,
nothing has to be looked up, and the value stored in the static
variable is returned.

This is both efficient (it only looks it up once and returns the
static variable) and self-healing, since if there's a code reset, it
will relookup the value.

Obviously, this only works with settings that can be retrieved from
a non-volatile source, rather than values that are calculated at
runtime based on data in forms that can vary.

The IP address part of the question is that for some reason the
server name does not always work as part of a path, but the IP
address does. I need to use network paths in some places, but on
some computers this has not been working. I expect it is a
configuration problem of some kind, but it seems it may not be
addressed any time soon, if at all.

This usually indicates improper workstation setup, either with the
wrong DNS server. The local DNS needs to be the primary (in most
small businesses, that's the domain controller), or you need to
designate a WINS server (WINS was the SMB networking answer to DNS,
but now that everybody uses TCP/IP, it's mostly unnecessary; that
became the case around the time of the release of Win2003 Server,
which finally added proper full support for DNS out of the box).

If there isn't a local DNS because there's no domain controller,
then you have to make sure that NETBios over TCP/IP is enabled. If
that is enabled, names will be resolved by broadcast over NETBios
(running on top of TCP/IP). If it's not turned on and there is no
mechanism for name resolution (no DNS and no WINS server), you'll
experience exactly the kind of problems you're describing.

If they are afraid to turn on NETBios over TCP/IP (it *is* a
security weakness if you're not properly firewalled), then they
should put the appropriate servername/IP address pair in the HOSTS
file on each workstation.

I know this is not *your* job to do, but perhaps providing them with
an explanation of what to do could goad them into fixing it.

I have found code to
convert server name to IP address. In my tests it works very
well.

It won't work in the cases where you are unable to use the server
name directly, because the API that looks up the IP address is just
as dependent on the proper name resolution setup as Access is when
using the server name directly.

I wonder
if there are potential issues with using the IP address rather
than the server name. If it is OK to convert, the server name
would be one of the LocationVariables, and I would run the IP
conversion code using that value.

The main issue is if the server changes IP address. That's the whole
point of having names for servers, so the IP address can change
without breaking the system.

If that's something that you know is relatively stable (i.e., won't
happen except when a server is replaced), then it's probably not too
much of an issue.

Personally, I'd be riding them to fix the configuration problem
because I'd make them sign an agreement absolving me of
responsibility when they break the Access app that is hardwired to a
particular IP address.

 

[David W. Fenton]

why not distribute a mde?

While MDEs are great for a finished application, during development
and beta testing, it's impossible to use, as users can't report what
code is causing an unhandled error, since the code isn't actually
there.

I have hardly any apps distributed as MDEs, because they are almost
all in constant development.

I can think of two that *ought* to be MDEs, but they are mature apps
that aren't experiencing code resets, so it's hardly a gain.

Certainly the larger the user population, the more attractive the
MDE becomes, but I currently don't have any apps in use by over 10
simultaneous users, and only one that is used by more than 50 users
total (and never simultaneously more than a dozen).

My MDBs don't lose most values in a code reset because I don't use
global variables, and use self-healing functions for initializing
data structures that are loaded from persistent storage. This means
that code resets almost never break my MDB apps -- they just
continue functioning, with everything being re-initialized
transparently after the code reset (as described in my reply to the
original poster).

I do that mostly for myself, because I experience far, far more bugs
than any end user ever does!

 

[BruceM via AccessMonster.com]

Thanks very much for the detailed information. Responses inline.

Some people use a form that is not visible, and assign values to text boxes
so they don't re-set.

However, why not distribute a mde? A mde forces your code to be compiled,
results in a smaller application, runs faster, and also ANY un-handled
NEVER re-sets global vars. So, a mde is strongly recommend for your
production software. (this assumes your application is split).

I used mde's for years since you don't need error handling (and in the
runtime un-handled errors don't shut down the application). The result
is a FAR more robust application when you do this.

I had not been using MDEs because there were some computers with Office 2000
and others with Office 2003, and there was some problem that I don't recall
now, but I never gave it another try. Now that everybody has Office 2003 I
will try again. I recall that I need to create the mde in the earliest
version of Office that will be in use, so maybe the same problem won't recur
as Office 2007 comes into use.

Yes, I seen the above also. It tends to be some wins resolution issue
and thus using IP is a ok workaround.

OK, good to know that. I don't know if the Wins thing is going to be
straightened out any time soon. I won't try to get into a lot of detail, as
it is out of my control, so I need to work with what I have.

Not really. I mean the server name stuff SHOULD work. And, if they
introduce a new server and the IP address changes, then you have to
re-link to the new server IP address. The other way around would
allow a new box to be introduced with the OLD server name, and
you would in theory not have to re-link. However, at the end of the day, I
really don't see a downside to using a IP address (the exception being that
if your IT department knew what they were doing, then the server name SHOULD
work).

I guess the initial table linking would have to be by way of IP address. I
was thinking of linking to graphics files and such, but then I remembered the
linking. (It is a split DB.)

The IP issue here is moot. If you need to change the \\servername, then you
need to change the IP address.

I assume the server would have a fixed IP address, but these days I'm not
sure what I can count on. My thinking was that when the server name is
initally entered into the LocationVariables table by way of a form, the IP
substitution code would run and be made to populate the appropriate field.
After that it would be checked at startup, just to be sure. Not sure that
this is necessary.

If you don't ever have to change the servername, then you don't have to
change the IP address. So, this is question is NOT related to using
\\servername or IP address. it is a legitimate question, but NOT related to
ip vs server name.

There will be a change of server at some point fairly soon. If the server
name recognition was working correctly it would be necessary only to change
that value in the LocationVariable table. I think IP address may be more
"foolproof" in that it shoudl work even when server name does not.

but it
should

[quoted text clipped - 7 lines]

a
message box advising them to contact somebody or other.

Well, this issue is how does your startup code manage the issue of linking
the tables from the from end to the back end. In other words, most everyone
has cobbled together some type of re-linking code that they use when
distributing their software. Again, this issue does not change if your using
an IP address or a server name.

I do have relinking code, but it only serves to advise of a problem. Having
the users use the relink dialog does not make sense in this situation. It is
more than I want to ask of them. I started working on something more
positive (using an ini file, as I recall), but I couldn't take the time
needed to sort that out.

In the case where I have physical use of the local network, then I link my
mdb to the back end (using unc pathnames, or in your case, an IP address).
You then create the mde, and then distribute that mde to each desktop. In
this case, we really don't need any startup code for re-linking.

However, for my many customers that I never seen, nor can I be on location,
then I create that mde, but it currently linked to my back end, and on their
networks, the data file location for the back is different. So, I have some
startup code that checks the current linked location, and the one that was
last used during linking (it placed in a text file in the program directory
where the mde is placed). So, during startup, if the current back end link
is wrong, then the re-link occurs. And, I should well note that SOME of my
clients that have the SAME problem as you (the server name craps out and
does not work they in fact link to the back end database file via an IP
address. However, my re-link code happy accepts both an IP address or a
server name...and I can't think any real problem that exists using IP or
server name (the exception being that the network and support people not
competent).

I will definitely try the mde. Thanks again. I'll post back when I have had
a chance to put some of this into action, which may not be for a few days.

 

[BruceM via AccessMonster.com]

Thanks for the information about the static function. I think I am gaining
an understanding of how those work. Thanks for the rest of the information
too. I got bogged down with something else today, but I will look at your
reply next week when I have a chance to study it more carefully than I could
today.

I am setting up a database that uses hard-coded values for things
such as the location address. However, the database will be used

[quoted text clipped - 10 lines]

functions, but still it seems that a global variable is
potentially fragile.

If the data you are contemplating storing in global variables is
itself stored in a table or any other persistent storage method
(registry, INI file, XML file, etc.) or is available outside Access
(from an API call), it's very easy to create functions that return
the value that are both efficient and self-healing (i.e., will
re-initialize after a code reset). I am strongly against global
variables and this is the kind of function I write all the time:

Public Function GetUser() As String
Static strUser As String

If Len(strUser) = 0 Then
If CurrentUser() = "Admin" Then
strUser = fGetUserName()
Else
strUser = CurrentUser()
End If
End If
GetUser = strUser
End Function

The key is the use of the STATIC variable, which unlike normal
variables, survives the scope of a call to the function. That is,
the first time you call the function, the static variable is
unitialized. Once you've called it, it is initialized and stays that
way until the next code reset.

So, you only look up the information once, stick it in the static
variable, and then, as long as there's not a code reset, the value
is returned from the static variable, instead of looing it up again.

In your situation, you might have something like:

Public Function GetIP() As String
Static strIP As String

If Len(strIP) = 0 Then
strIP = DLookup("Value","tblConfig","[Key]='ServerIP'")
End If
GetIP = strUser
End Function

That assumes you have your data stored in tblConfig, with Key and
Value columns. The first time you call it, the static variable is
uninitialized, so it calls the DLookup() to find the value, and puts
it in the static variable. The next time the function is called,
nothing has to be looked up, and the value stored in the static
variable is returned.

This is both efficient (it only looks it up once and returns the
static variable) and self-healing, since if there's a code reset, it
will relookup the value.

Obviously, this only works with settings that can be retrieved from
a non-volatile source, rather than values that are calculated at
runtime based on data in forms that can vary.

The IP address part of the question is that for some reason the
server name does not always work as part of a path, but the IP
address does. I need to use network paths in some places, but on
some computers this has not been working. I expect it is a
configuration problem of some kind, but it seems it may not be
addressed any time soon, if at all.

This usually indicates improper workstation setup, either with the
wrong DNS server. The local DNS needs to be the primary (in most
small businesses, that's the domain controller), or you need to
designate a WINS server (WINS was the SMB networking answer to DNS,
but now that everybody uses TCP/IP, it's mostly unnecessary; that
became the case around the time of the release of Win2003 Server,
which finally added proper full support for DNS out of the box).

If there isn't a local DNS because there's no domain controller,
then you have to make sure that NETBios over TCP/IP is enabled. If
that is enabled, names will be resolved by broadcast over NETBios
(running on top of TCP/IP). If it's not turned on and there is no
mechanism for name resolution (no DNS and no WINS server), you'll
experience exactly the kind of problems you're describing.

If they are afraid to turn on NETBios over TCP/IP (it *is* a
security weakness if you're not properly firewalled), then they
should put the appropriate servername/IP address pair in the HOSTS
file on each workstation.

I know this is not *your* job to do, but perhaps providing them with
an explanation of what to do could goad them into fixing it.

I have found code to
convert server name to IP address. In my tests it works very
well.

It won't work in the cases where you are unable to use the server
name directly, because the API that looks up the IP address is just
as dependent on the proper name resolution setup as Access is when
using the server name directly.

I wonder
if there are potential issues with using the IP address rather
than the server name. If it is OK to convert, the server name
would be one of the LocationVariables, and I would run the IP
conversion code using that value.

The main issue is if the server changes IP address. That's the whole
point of having names for servers, so the IP address can change
without breaking the system.

If that's something that you know is relatively stable (i.e., won't
happen except when a server is replaced), then it's probably not too
much of an issue.

Personally, I'd be riding them to fix the configuration problem
because I'd make them sign an agreement absolving me of
responsibility when they break the Access app that is hardwired to a
particular IP address.

 

[BruceM via AccessMonster.com]

Thanks for the reply. I put a comment into a reply to David that I think I
understand better how static functions work, but then I realized his post was
not about a static function (yours was), but rather a static variable (I
think). I don't have any more time today to look at this, but there is much
to study next week. Thanks to all for the help and comments.

I have never used IP addresses in Access, so I can't address that issue, but
I do have a suggestion on storing those values once.

You can use a Static Function in a standard module to store and retrieve the
value. It will not be affected by an unhandled error.

Here is an example:

Static Function GetSSN(Optional ByVal varNewSSN As Variant) As String
Dim varSSN As Variant

If Not IsMissing(varNewSSN) Then
varSSN = varNewSSN
End If
GetSSN = varSSN
End Function

When you pass a value to the function, it stores it in the varialbe varSSN.
If you call the function with no argument, it will return the stored value.
So in your startup form, you might do something like this:

GetSSN(Dlookup("[enteredon]","[tblClient]","[MainName] = ""Jones"" AND
[FirstName] = ""Martha"""))

When you need to retrieve it, it is just a function call:

strEnterDate = GetSSN

Actually, there are a couple of questions here. I will get to the topic in
the subject line shortly, but the first question leads to that one.

[quoted text clipped - 30 lines]

it to the table value. If they match, no problem. If not, they could get a
message box advising them to contact somebody or other.

 

[Klatuu]

Based on what you want, Static Variable and Static Function are about the same.
The main difference is in a Static Function, all variables in the Function
become Static. If you use a Function with a mix of Static and normal
variables, then a Function with the variables you want to save dimmed as
Static is the answer.
--
Dave Hargis, Microsoft Access MVP

Thanks for the reply. I put a comment into a reply to David that I think I
understand better how static functions work, but then I realized his post was
not about a static function (yours was), but rather a static variable (I
think). I don't have any more time today to look at this, but there is much
to study next week. Thanks to all for the help and comments.

I have never used IP addresses in Access, so I can't address that issue, but
I do have a suggestion on storing those values once.

You can use a Static Function in a standard module to store and retrieve the
value. It will not be affected by an unhandled error.

Here is an example:

Static Function GetSSN(Optional ByVal varNewSSN As Variant) As String
Dim varSSN As Variant

If Not IsMissing(varNewSSN) Then
varSSN = varNewSSN
End If
GetSSN = varSSN
End Function

When you pass a value to the function, it stores it in the varialbe varSSN.
If you call the function with no argument, it will return the stored value.
So in your startup form, you might do something like this:

GetSSN(Dlookup("[enteredon]","[tblClient]","[MainName] = ""Jones"" AND
[FirstName] = ""Martha"""))

When you need to retrieve it, it is just a function call:

strEnterDate = GetSSN

Actually, there are a couple of questions here. I will get to the topic in
the subject line shortly, but the first question leads to that one.

[quoted text clipped - 30 lines]

it to the table value. If they match, no problem. If not, they could get a
message box advising them to contact somebody or other.

 

[David W. Fenton]

I have never used IP addresses in Access, so I can't address that
issue, but I do have a suggestion on storing those values once.

You can use a Static Function in a standard module to store and
retrieve the value. It will not be affected by an unhandled
error.

Here is an example:

Static Function GetSSN(Optional ByVal varNewSSN As Variant) As
String Dim varSSN As Variant

If Not IsMissing(varNewSSN) Then
varSSN = varNewSSN
End If
GetSSN = varSSN
End Function

When you pass a value to the function, it stores it in the
varialbe varSSN. If you call the function with no argument, it
will return the stored value.

Hey, I didn't know about static functions.

But I think my version is easier, since it encapsulates all the
logic needed to look up the information, and will re-initialize
itself after a code reset.

 

[BruceM via AccessMonster.com]

All of this stuff is within one company (the one I work for), so there is
little I can do in terms of pressure. The databases are local initiatives,
and the network administration is global, so this problem seems not to be
high priority.

I truly appreciate the time you have put into your responses. I now have
some things to suggest (I have checked out the WINS/DNS/HOSTS things as well
as I could, but we are in the midst of something that allows little spare
time, including responding in the newsgroups). I will do what I can to get
the computers fixed so they recognize the server names, because converting to
IP addresses is more than I can undertake just now.

Again, thanks. Sorry I have had so little time to reply or try to put
suggestions into action, but again I thank you for ideas I may be able to
study more fully at a later date.

I am setting up a database that uses hard-coded values for things
such as the location address. However, the database will be used

[quoted text clipped - 10 lines]

functions, but still it seems that a global variable is
potentially fragile.

If the data you are contemplating storing in global variables is
itself stored in a table or any other persistent storage method
(registry, INI file, XML file, etc.) or is available outside Access
(from an API call), it's very easy to create functions that return
the value that are both efficient and self-healing (i.e., will
re-initialize after a code reset). I am strongly against global
variables and this is the kind of function I write all the time:

Public Function GetUser() As String
Static strUser As String

If Len(strUser) = 0 Then
If CurrentUser() = "Admin" Then
strUser = fGetUserName()
Else
strUser = CurrentUser()
End If
End If
GetUser = strUser
End Function

The key is the use of the STATIC variable, which unlike normal
variables, survives the scope of a call to the function. That is,
the first time you call the function, the static variable is
unitialized. Once you've called it, it is initialized and stays that
way until the next code reset.

So, you only look up the information once, stick it in the static
variable, and then, as long as there's not a code reset, the value
is returned from the static variable, instead of looing it up again.

In your situation, you might have something like:

Public Function GetIP() As String
Static strIP As String

If Len(strIP) = 0 Then
strIP = DLookup("Value","tblConfig","[Key]='ServerIP'")
End If
GetIP = strUser
End Function

That assumes you have your data stored in tblConfig, with Key and
Value columns. The first time you call it, the static variable is
uninitialized, so it calls the DLookup() to find the value, and puts
it in the static variable. The next time the function is called,
nothing has to be looked up, and the value stored in the static
variable is returned.

This is both efficient (it only looks it up once and returns the
static variable) and self-healing, since if there's a code reset, it
will relookup the value.

Obviously, this only works with settings that can be retrieved from
a non-volatile source, rather than values that are calculated at
runtime based on data in forms that can vary.

The IP address part of the question is that for some reason the
server name does not always work as part of a path, but the IP
address does. I need to use network paths in some places, but on
some computers this has not been working. I expect it is a
configuration problem of some kind, but it seems it may not be
addressed any time soon, if at all.

This usually indicates improper workstation setup, either with the
wrong DNS server. The local DNS needs to be the primary (in most
small businesses, that's the domain controller), or you need to
designate a WINS server (WINS was the SMB networking answer to DNS,
but now that everybody uses TCP/IP, it's mostly unnecessary; that
became the case around the time of the release of Win2003 Server,
which finally added proper full support for DNS out of the box).

If there isn't a local DNS because there's no domain controller,
then you have to make sure that NETBios over TCP/IP is enabled. If
that is enabled, names will be resolved by broadcast over NETBios
(running on top of TCP/IP). If it's not turned on and there is no
mechanism for name resolution (no DNS and no WINS server), you'll
experience exactly the kind of problems you're describing.

If they are afraid to turn on NETBios over TCP/IP (it *is* a
security weakness if you're not properly firewalled), then they
should put the appropriate servername/IP address pair in the HOSTS
file on each workstation.

I know this is not *your* job to do, but perhaps providing them with
an explanation of what to do could goad them into fixing it.

I have found code to
convert server name to IP address. In my tests it works very
well.

It won't work in the cases where you are unable to use the server
name directly, because the API that looks up the IP address is just
as dependent on the proper name resolution setup as Access is when
using the server name directly.

I wonder
if there are potential issues with using the IP address rather
than the server name. If it is OK to convert, the server name
would be one of the LocationVariables, and I would run the IP
conversion code using that value.

The main issue is if the server changes IP address. That's the whole
point of having names for servers, so the IP address can change
without breaking the system.

If that's something that you know is relatively stable (i.e., won't
happen except when a server is replaced), then it's probably not too
much of an issue.

Personally, I'd be riding them to fix the configuration problem
because I'd make them sign an agreement absolving me of
responsibility when they break the Access app that is hardwired to a
particular IP address.