Avoid delay when open file with external sources (not network connection)

[innodat]

Does anyone have an idea how the long delay when opening a file with missing external (filemaker) data sources can be bypassed?

I would like to pull data from a filemaker file on a remote server, but only if a network connection is present. Currently, the user gets a pretty nasty delay (20 seconds?) and a dialogue which asks him/her to locate the file. Very confusing. Even worse, this happens for EVERY file reference.

Can a FM file be accessed without storing the reference in the external data sources dialogue?

Can the check and message be suppressed?

Any "thinking outside of the box" most welcome! I just don't get anywhere myself...

Thanks!

[Vaughan]

Try this:

open the file with a layout that does not have any field on it. run a script with the Open File step and trap for errors: it might still pause but it might not prompt to locate the file.

The question is, what to do if the file is not available? Any thong that you do that makes FMP look for the related data will probably cause it to go searching again.

[innodat]

I just created an empty test-file with your suggestion above - no delay, only when I'm accessing a layout with elements from the (unavailable) remote file. It seems I can eliminate the problem by scanning my start-up script and associated layouts for references to the remote files. Once cleaned-up, there should no more delays. I will post my findings here...

Thank you for leading me into the right direction!

[Vaughan]

There is also a behaviour (discussed by an FMI engineer on TechTalk) where the file remembers the last used layout and open with this even before the file options are run. So it's good have a shut-down script that changes the layout before closing the file.

[LaRetta]

There is also a behaviour (discussed by an FMI engineer on TechTalk) where the file remembers the last used layout and open with this even before the file options are run. So it's good have a shut-down script that changes the layout before closing the file.

That is not my experience, Vaughan and I wonder if it is a platform difference or whether one of us (FMI or myself) are incorrect in our understanding. I tested this thoroughly few years ago and just confirmed again using 11.0v3 (latest updater for Windows). Here is my understanding:

• A file will open on the layout you were on when you last made a schema change (layouts, scripts, field definitions...). I will call this layout the schema layout. This means you can also be in Browse mode and your current layout will become your schema layout if you change a script, for example.
  
• Using Startup script to specify your opening layout is not a good choice because Startup runs after schema layout has opened (so you can still get major slowdown and/or flash if the layout is heavily aggregate-burdened).
  
• If you specify File Options > Switch to Layout[Menu] then Menu layout will be the first window (and will always open instead of the schema layout and before Startup script runs.
  

Here is a file to assist in testing. Using debugger helps but even without, the results are obvious because I pre-loaded the Data list with dummy aggregate-nightmare calcs and 5,000 records. Close file between each test but you can keep FileMaker and debugger open.

Test #1: Data list layout was modified and you will see that you can close and restart FileMaker repeatedly and it will always open on the Data layout if you do not make schema changes at all (you can find, go to preview mode, print). You can do anything in Browse that you wish. It will always open on this Data List layout.

Test #2: Switch to the Menu layout then make any schema change (layouts, scripts, field definitions, or simply move a box in the graph). Close and open file under debug. It starts on Menu layout.

Test #3: Make a change while on Data layout to re-establish it as the schema layout. Then go to File Options and enable Switch To Layout [ Menu ]. Close and open file. It starts on Menu layout and debug shows clearly (and you can see with your own eyes) that the Data layout is ignored and Menu is all that fires.

I currently use File Options Switch Layout to specify my opening layout and I drop the layout switch from Startup script. With this setup, I never have to worry about this particular trap; no matter what changes I make and when I make them, the opening layout in File Options is first window. Neither will it be necessary to run script upon close to change layouts (which I doubt would ‘hold’ when the file reopens anyway). It is important (and intriguing) to pin down the rules on this process and also be sure it is cross-compatible. I would really appreciate help on testing it. I am pretty confident of my findings on Windows XP but that is small number of OS/versions using FileMaker.

FileOpen.zip

[Vaughan]

Perhaps I should have qualified that this happens in single user mode, when the file is written to (schema change etc).

The quote form the engineer:

Make sure you don't have any "hidden" fields on your blank layout - fields colored the same as the background, etc.

When a file opens it uses the last window open at time of file closing on a 'local' host. But, not if there were no changes to the file requiring it to save changes to disk. Switching windows is NOT a change the file needs to save. Changing data or a layout or a script is a saved change.

When the file opens on the server it uses the 'last layout" to open the file. Not the Switch to layout designated in the Options. It is very frustrating to have everything set up and appear to be working locally only to have the file misbehave when put on FMS. Sometimes you don't see this until you open over a WAN or some other unexpected behavior like related files opening.

I suggest you close the file on FM Server (verify it really is closed),

Open it with a local Copy of FMP Advanced (the window must NOT have a server designation),

switch to the blank layout

resize window (DO NOT make it off screen in any way as this causes FMP to first open the window full screen causing a screen flash in a high latency network),

make a change that must be saved (changing a layout and switching it back may not be a saved change so a data change is better),

switch on the script debugger (this requires FM Advanced)

close the file,

Open the file with the script debugger open so you can cancel the script and make sure no other files are open.

You may have to repeat and rinse a few times to get it right. Also, I recommend making a closing script to set up the file for serving. Make sure the layout and window location are set correctly for the opening process you want.

[innodat]

This is fascinating - I'm glad for the discussion. I could have cleaned up all my scripts and layouts, put the file on the server, and experienced the very same problem. All because... I did not know about FileMaker opening the layout "on which" the last change (written to disk) has occurred.

I mean who does?? This clearly shouldn't be the case. The layout defined in the file options should be the very first layout FileMaker is calling. The function is very misleading otherwise! Sometimes I wonder...

[Vaughan]

The layout defined in the file options should be the very first layout FileMaker is calling.

This was discussed in detail in TechNet excessively.

FMP has to FIRST open the file, then read what the file options are, then perform them. It's that FIRST opening the file part.

I should probably add that this discusses things are are *implementation detail* for the way FMP works. It's not documented because implementation details change without notice, and artefacts of particular implementation details should not be relied upon for functionality. So at the time that was written (a couple of years ago) that was the cause and solution to a problem somebody had of related files being referenced even though the file options were set to go to a blank local layout. Things may change without notice.

On implementation details: the bus you catch to work every morning is red, so you tell people to get on the red bus to go to work. The bus colour is an implementation detail and could change (say the usual one breaks down). Instead the bus should be identified by the route number. There are mechanisms to warn people when the route number changes, but not the bus colour.

[innodat]

I understand your point of view. I missed out on that discussion on TechNet.

It's here now and can be found by more people - thank's again for sharing.