30-second pause on new-record creation - DNS resolution issue?

[Gilbert Osmond]

Problem: In many different databases (all based on a common template DB I made some months ago,) suddenly FM Pro started hanging with a 30-second beach-ball pause on every attempt to create a new record. It would then continue working normally -- the pause only occurred on every new record creation.

Proximate Cause: A text field I call "CreationHostIPAddress", set to Auto-Enter Calculation, as follows:

Get ( SystemIPAddress )

In normal conditions, this calc populates the field with the IP address of the local machine. It had been working fine for many months.



A week or two ago, I installed a software VPN client on my machine (VPNTracker 6..) It took me until just now to figure out that the 30-second hang on new-record create in FM Pro was caused by a slow or hung DNS lookup, which *only* happens when the VPN client software is open and running.



The VPN client creates an alternate host IP address, 10.1.2.3, which Filemaker Pro probably tries to resolve using a DNS query, but of course no DNS server anywhere has an answer for 10.1.2.3, that IP being part of the blocks reserved for testing & private use.



I tried making an entry in /etc/hosts to resolve this issue --

10.1.2.3      localhost

but even after a DNS cache flush, it still continues. Anyone run into this problem in the past?

My goal is to be able to run the VPN client, make one or more VPN connections, and still run FM Pro normally.

In the meantime I'll just quit the VPN client when I need to create new records in FM.

[Vaughan]

I have no idea why you want to track the host ip address.

However it is something should not change in a session so it's possible to set a global field at file open ONCE and refer to that for the whole of the session.

[Gilbert Osmond]

With due respect, I have my own reasons for wanting to track IP address on a per-record basis, and to know if it changes during a Filemaker session: it's part of a security-focused audit trail. For example, a user may leave their FM app open for hours to weeks at a time, through sleep-wake cycles and certainly through network-location changes. Using the built-in Get() function to grab the current IP address is cleaner and simpler than trying to work up an external script to push network location change info into FM Pro from outside it.

I'll appreciate other replies that may address the technical problem itself directly.

Edited August 3, 2010 by Guest

[Vaughan]

AFAIK the IP number should NOT change in a session: if it does then the network connection will be broken and the client will be disconnected from the server. There will be no more databases open even if the FM Pro client program is still running.

There may be some weird possibilities with roaming in wireless networks but again, if the network connection breaks for an instant the databases are gone.

FMS allows clients to be disconnected after a period of inactivity. This might be useful for you.

Using the built-in Get() function to grab the current IP address is cleaner and simpler than trying to work up an external script to push network location change info into FM Pro from outside it.

Except it takes 30 seconds each call. Setting a startup script to call the function once and store it in a global field or variable is not at all difficult and seems like a good work-around. This would not be an external script: it can all be done in FMP natively.

[Gilbert Osmond]

AFAIK the IP number should NOT change in a session: if it does then the network connection will be broken and the client will be disconnected from the server. There will be no more databases open even if the FM Pro client program is still running.

I should've made it clear in my initial post: the solution is not based on FM Server / Client; it's based rather on a local FM db file being opened in a local copy of the application.

Except it takes 30 seconds each call.

That is not normal behavior; when functioning properly the call is transparently short. Obviously the 30-second delay is anomalous. I'm interested in finding the *source of that delay* and fixing it.

Setting a startup script to call the function once and store it in a global field or variable is not at all difficult and seems like a good work-around. This would not be an external script: it can all be done in FMP natively.

As I said in a previous post, this kind of solution does not address the situation where a user's IP address changes between quit & re-open of a database, for example if the DB is left open in the background for days or weeks at a time through sleep/wake cycles. In that period there could easily be 10 to 15 IP changes as a mobile user goes from one network to another.

I appreciate your suggestions, but in some cases what is needed is a direct fix for the problem at hand. I think it's becoming clear to me that this issue isn't really Filemaker Pro per se; rather it's a situation in the OS-level DNS resolver that needs to be fixed.

If anyone has specific suggestions for *how to resolve the problem as I've stated it,* I will appreciate them.