More and more of my clients seem to see this message dialog come up when starting my solution database along with DayBack.



It's not all the time of course which has made this infuriating. However I started to look at just how my startup sequence works. Here is a basic run down (I have three files and one of them is DayBack. The central file is Called 'Main'):

Go to Layout (Welcome Screen; Main)
Freeze Window
Open (File 2; Hidden)
Open (DayBack; Hidden)
Select Window (Main)

Please note that Dayback is set to run it's startup script on first window opened. This script works just great on my server and with any of my development worstations. However I do occasionally get issues on iPad.

After thinking about this a bit, and how Dayback wants to render out it's calendar screen on startup, I decided to remove the Open Hidden command. I noticed that the issue resolved. I tested it on my devices here and on several workstations and it seemed pretty good. As I've said previously this issue is intermittent so I'm watching things carefully here. Anyone have any thoughts on this?

I think that's a very smart change. I'm not sure exactly why "hidden" would cause problems, but when the problems are only intermittent AND they're on startup, we tend to think about timing issues and I can imagine the timing of when a file is "open and available" to the URL process differs when the machine is busier and differs more when hidden is used.

Nice work.

Well my thoughts started with the understanding that the calendar is displayed in a Web Viewer and wasn't sure if the refresh would be affected by a "hidden" setting. Couple that with the fact that I really don't know if it would be sort of like having a portal running a complex calculation on a secondary tab (the calculation doesn't run until the tab is called as front-most). Anyway it seems to be working for me today but I've yet to hear back from my client's environments.

I have noticed a similar problem, but while working on my Win8.1 laptop, FMA17.

I open my app (remote), everything is fine, when I open the Dayback original file (local) to update the script step in my app at some point I will get that error message too.

Close Dayback, close my app, open my app, get the error message.

Close FMP, re-open my app, message no longer shows up

Can you give me a bit more details about what you're doing here...

"I open my app (remote), everything is fine, when I open the Dayback original file (local) to update the script step in my app at some point I will get that error message too."

I'm just not sure I'm following the steps to reproduce this: what script step are you updating? Are there two copies of DayBack running at this point, one hosted and one local?

Thanks for the details,

John

On my laptop W8.1, I use FMP17A.

My app, I have integrated Dayback into it. My app is hosted on FMS.

When a new version is available, some of the script needs to be manually updated from your new fresh DayBack.fmp12

So I open my app remotely PLUS I open the DayBack.fmp12 to get copy/paste the script step.

So Yes I have 2 copies open.

The weird thing is at the office on Win7, I do it the same way, but never had any issues about the FMP protocol and I use FMP16A

Hi jffortier,

In a scenario where you have multiple instances of DayBack opened at the same time (like when you're updating scripts), this error message is expected. What is happening is that when the scripts are triggered from the second file, FileMaker runs the requested script in the first file that it can find named "DayBack.fmp12", which is usually the first file you opened. Then, the OnTimer script in the second file is run to verify that the FMP URL script call was successful (which it wasn't in this file), so you see the error.

This error is expected can be ignored when updating scripts in your main file. You should only really see this error when first opening the second copy of the file (or if you refresh the calendar or run "Upon Opening" in the second file during the updates).

Sincerely,

KC

I didn't think it was possible to get this error message on FMGo ?!?!




It only did once, re-run script and it didn't came back...

Hi jffortier,

We still use the FMP URL protocol to call scripts in FileMaker from the calendar WebViewer in FileMaker Pro, so you might still receive this message if things don't work right with the FMP URL protocol.

If the calendar eventually loads after receiving that message, it might just be that network or performance issues are causing the calendar to load slower than the check for FMP URL is expecting. You can allow more time before the "Check For FMP URL" script runs by adding an additional 5 or 10 seconds to the interval of the "Install OnTimer" script on line 25.

Let me know if that helps!

Regards,

KC

Yep. That's the error I see see periodically also. I'd say for every 10 launches of DayBack under iPad/iPhone 2 of them show this message (for me that is. YMMV) It happens on my server (Windows with very little traffic) and on my client's servers (mostly Mac with light traffic). I tried to extend the timing on it to delay the wait for response and that really didn't do much to resolve things.

For information, Win users: I installed FMP18 just for fun to see what's new, but removed it after 2-3 days.

After that I started to have FMP URL message... well when you uninstall FMP18 the registry key for FMP is deleted too... you need to start >control panel >programs and features and do a repair on the FMP17 app to fix the missing protocol.

Yep, I'm back on this thread after pulling my hair out on this one, once again! I'm running Dayback Classic 10.60 under Mac OS 10.13.6 and FMA18 (server is FMS18 under High Sierra 10.13.6 - separate computer). Today I suddenly get the FMP URL error on starting Dayback. This time I can't get it to show any events at all. In fact, most of the time the startup routine doesn't even complete. This is after just closing the file and having it run just fine for months. And no, I didn't just alter the startup script or the FMP URL script. The FMP URL Script is set to 10 seconds delay as directed above, and which is worked just fine for months.

I moved over to my Windows machine (WIN 8.1 FM18.0.3) and started it from there. It occasionally shows the FMP URL error but at least shows the events and appears to completes the startup routine. I opened Dayback several time on the Windows side and half the time the error appeared but always showed the Events.

So I started to delete the MANY copies of FM I have on my drive leaving only Filemaker 15 (which I need for some clients). I reinstalled FMA18 and applied the last update for 18.0.3. Same issue of non-completing startup, FMP URL error and no events. I checked the FMP URL protocol by copying and pasting the appropriate URLs into a browser and it seemed to respond normally. So At this point I think there is something up with my Mac but since I occasionally get the FMP URL error on the Windows side I can't be sure. Suggestions?

--UPDATE: DayBack suddenly started to work again. I see events and it seems fine now. I really don't get it.

Hi Jim,

The FMP URL check is validated by making sure the calendar web viewer tries to query events within 5-seconds (or 10 in your file). If anything prevents the calendar web viewer from loading, then you'll see this error.

So if you're not seeing the calendar load in the web viewer, then you'll need to find out what's causing that to happen.

Most of the time, this is an issue with additional script steps after one of the scripts that tell the calendar to load or refresh. In the case of the Upon Opening script, if you have any script steps that run immediately after the "Go To WebViewer Calendar..." script, this can cause issues with the calendar loading. This also means that the "Upon Opening" script needs to be the last one run in your main startup script.

DayBack Classic depends on the FMP URL protocol to request that FileMaker perform a script to query events. If any other scripts are running when this FMP URL call is performed, they can conflict with the query script, especially if those scripts change the focused window or layout.

Let me know if that helps troubleshoot the issue.

Regards,

KC