The guru built opener scripts for access to the server.

We put the LAN address [192.168.1.20] first; then the WAN equivalent.
That way, one script gets sent around to all users desktops; be they in
house or out...

The in-house folks connect via the LAN; no delay in going out the
firewall and back in.

BUT, the people outside have to wait a long time, 70 seconds, before it
times out on the LAN and tries the WAN address.

Is there any way to change that timeout?


--
A host is a host from coast to coast.................wb8foz (AT) nrk (DOT) com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

On Jun 18, 8:01 pm, David Lesher <wb8... (AT) panix (DOT) com> wrote:
An ideal solution would be to just deploy via DNS instead of hard
wired IP addresses. Then its just a matter of ensuring that a given
address returns the LAN address on the LAN and the WAN address from
the WAN.

Then fmdatabase.mydomain.com would translate to 192.168.x.x. on the
LAN and whatever your WAN address is elsewhere. The technique is
called split-brain DNS and is quite common. The only hiccup is laptops
that move from WAN to LAN and back again without a reboot may cache
the wrong DNS entry and try resolving on the wrong address, but there
are solutions to that. (e.g. very low TTL on that particular DNS
record) Worst case, the user has to reboot. Or you could have the
opener script flush the dns cache or something like that.

Of course this means you'll need to run a DNS server for the LAN, and
if you're entire network infrastructure amounts to DHCP from a linksys
NAT box, then its probably not the right way to go.

---

The other 'all in filemaker' solution would be to define the WAN and
LAN access to the database on separate file references, and then open
the appropriate one. Perhaps your startup script can automatically
determine if its on the LAN or WAN, or if not, simply prompt the user
with a button (for laptops that move between), and let fixed-
workstations save a preference on which reference to use.

But really, solving it at the DNS level is the more professional/
robust solution. (e.g. you can then move the server to a new ip
address and it will continue to work, provided you update dns
appropriately.)

cheers,
dave

d-42 <db.porsche (AT) gmail (DOT) com> writes:

Thanks; but I really don't want to add that level of complexity.
For this size operation; it's easier to tolerate the delay or
issue "inside" & "outside" openers....



--
A host is a host from coast to coast.................wb8foz (AT) nrk (DOT) com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

How about using Get(SystemIPAddress) to see if they are on your
private network.

It could still cause the delay if the travelling user were on a
similarly set up NAT network, but it would help.

On Jun 19, 6:57 am, David Lesher <wb8... (AT) panix (DOT) com> wrote:
Then see the second suggestion I made using 2 distinct file
references, and selecting between them.

You still would only need one opener file, and you can dodge the
delay. Having the opener detect whether or not you are on the LAN or
WAN automatically would be a challenge -- Paul's ip address suggestion
could work, but really the IP range is so widely used it probably
wouldn't be useful. I'd recommend just giving the user the choice.

If you wanted to use the GetIP address Paul suggested you would
probably be pretty successful if you changed your lan to run on
something unusual like 192.168.76.x for example.

And even better solution would be some sort of functionality to
resolve a particular domain name that would only be resolvable on the
LAN (back to using DNS though), or testing the domain name. (some dhcp
servers [even those built into NAT boxes] let you assign a domain
name. If you set it to 'mycompanyname.lan', and then tested for that,
you'd probably be nearly 100% reliable.

-cheers,
Dave