If you try to run a script that are trying to connect to a hosted database and you have not 3G/WiFi it will of course show you a error. Best thing is to handle this in your scripts.
Set Error Capture (On) and then you have to handle all the errors.
Do find out if you have a connection to your hosted database you can do several things, but what is most often do is to check
If (Field in hosted database not is empty)
Just adding to this, use a script before anything is attempted to be shown on the layout and use set error capture to on during that script to suppress the warning.
Using a trigger like OnFirstWindowOpen would work, or OnLayoutLoad
The error will appear any time you have the external data source on your Relationships Graph for the file that's open. This is because FileMaker caches the joins on the Graph when the file opens. If the file's not available (for whatever reason), FileMaker will ask the user to locate it.
The way around this is to use a connector file for syncing, rather than attempting to do it from the main database. In your case, since you never want to use the photos unless you're online, I suggest moving the table to another file altogether. Open it only if you're online and can connect (as suggested by Johan). If you're not able to connect, simply don't open the external file that connects to the photos.
There are products that you can use to sync data between your files so that you need to FileMaker connection between your files.
are just two out of many
Thank you Johan,
I tried adding a script to trigger on OnFirstWindowOpen,
where the first line of the script was Error Capture ( on )
but when the iPad is taken off line and the DB started
there is an alert box presented that says:
The file “Photos” could not be opened. (Not Found)
further options are only to cancel or reconnect.
So perhaps the DB is checking this before the first window is opened.
I am using Tim's FMEasySync and it does not have this issue in spite
of also referencing an external data source. Possibly since
it does not directly reference any field within that external data source.
Possibly since it does not directly reference any field within that external data source.
It's my understanding that this is the case. When something in your file references actual data from that source, FileMaker will attempt to open the file and will generate this error when it fails. That is basically any reference to a field from that table's schema--whether in a script or on a layout.
Thank you Mike for the thoughtful response,
" In your case, since you never want to use the photos unless you're online, I suggest moving the table to another file altogether. Open it only if you're online and can connect (as suggested by Johan). If you're not able to connect, simply don't open the external file that connects to the photos."
Looks like FMGo tries to open External Server based Photo_DB Photos table automatically.
So I am not sure I have the choice to simply not open it. Perhaps I have misunderstood
what you are suggesting?
• I have Photo_DB in the list of external data sources ( the table is in a separate DB file on the server )
• I have include a table "Photos" in the FMGo DB graph that references a table within the external data source.
• I have "Photos" index field related to one of the fields in the primary table resident on FMGo
• I have several container fields in FMGo that reference fields in the "Photos" table.
Split the photos table out into a completely separate file. Don't load that file to the mobile device. Then, there will be no TOs
on the mobile that point to the hosted file. Therefore, it won't try to open it and you avoid the issue entirely.
Shorter: Avoid having any pointers to files that aren't available. That's where the error is coming from.
hummm… so "any reference to a field from that table's schema--whether in a script or on a layout."
but not the table itself in the relationship graph?
I was hoping that if I just made the fields hidden, then when it was not connected the error would not be raised...
but I was trying to hide them onFirstWindowOpen, maybe if by default I have then hidden then make them visible only if online.
Any idea if the error is raised when fields are hidden?
I will give it a try.
The error happens as soon as you open the file if any TO pointing to the external table is on the Graph. You cannot trap it or avoid it other than by not having the TO on the Graph.
It sounds like the only solution to this issue would be keep it as an external data source, take it off the graph, and use a server side script to move a photo contained a local container into the server Photos_DB. Perhaps retaining a much resized smaller version of the photo in the FMGo local database. I guess that I could then have another server side script that could return the full size photo when required.
Not quite so elegant as I would like, but maybe it would work.
Thank you for the quick answers
The first layout that you go to have to be a layout without and fields on at all. Table occurrence have to be a local table. Then FileMaker want ask for your hosted file
Originally, you said there were no photos held locally. Now, you're saying you need to "move a photo contained [in] a local container into the server" file. So which is it? Do you have photos locally, or not?
I stand corrected on the TO issue. Johan is right. As long as you don't do anything that requires that file to open, it won't try. This includes fields on layouts (including calculation fields that reference the external table), script steps, and opening the Manage Database dialog (which isn't a concern on Go). So if you can omit all that, then the error won't fire.
However, if you need to have the photos locally, then you'll have to store them locally. I don't know what the workflow here is, but perhaps have the photo capability just for selected records and then move them up to the server when you have a connection?
One option would be to have a local photos DB in a separate file that's only referenced if needed.
FileMaker advertises that you can take the same database and run it on any of its delivery methods (WebDirect, Pro / Advanced, and Go). That's fundamentally true, but, in many cases, it's beneficial to have separate versions of the database for the different delivery platforms for optimum performance.