Troubleshooting DayBack for FileMaker
General Troubleshooting
Times down the left-hand side are all random like 10:08
Visit "Time Scales" in the left-hand sidebar of Admin Settings and you've likely entered an odd time into one of the settings like "earliest time visible". These values should be in the form HH:MM:SS like 06:00:00 for 6am. If you enter 06:07:00 you'll see odd results.
DayBack Won't Load
There are two FileMaker scripts that may help. Run one or both of these if you just see the blue loading bar but no calendar:
Go to Admin Settings - DayBack This will take you to admin settings and reset the web viewer.
Sign Out - DayBack Signs you out and takes you back to the sign-in page. More: how to sign out with a FileMaker Script.
If you believe the loading problem is because you've been writing custom app actions that may not function, here's how to get DayBack to bypass them: close the FileMaker file and re-open it while holding down the shift key and moving the mouse back and forth as you arrive at the calendar layout. This will take you straight to DayBack settings where you can turn off your app action by unchecking the box next to "app" below the action.
I'm Seeing Two of Each Event
If you've created any App Actions, check that the action's "Prevent Default Action" is set correctly. If that's set to NO and your action is using action.callbacks.confirm(); you're essentially telling DayBack to render the calendar twice.
The Calendar is Blank (or one Source is Blank)
The most common cause of events not showing up is that you have some filters applied and no events match those filters. If you're filtering for a particular status (or calendar, or resource) and then create a new appointment with a different status, that event will disappear since it doesn't match the filters you have in place. Clicking "Clear filters" at the bottom of DayBack's filters tab in the left-hand sidebar will bring these events back if that's the case. If that doesn't help, try these ideas...
Double Check Your Field Mapping
Go to admin settings and select the calendar you're interested in. On the Calendar Info tab, click "Validate Layout" and "Validate Table Occurrence". Click on the Field Mapping tab and scroll all the way down: click "Validate Field Mapping," correcting any issues you see.
Incorrect Contact or Project Table Occurrence Names
If your events are linked to contacts/projects AND your events table is in a different file than the file DayBack is in, be sure the contact and project table occurrence names in DayBack are the same names those table occurrences have in your events file. If you change the table occurrence names in DayBack, be sure to change the names used in Field Mapping and Related records. More details here: Setting up Contacts & Projects.
FileMaker Errors when Editing Events
Some tips for errors you might see when dragging events around or editing them...
Windows and High DPI Screens
On Windows systems with a smaller screen and a high DPI (resolution), the calendar text and objects may display very small and unreadable. There are a couple of options to address this, some of which are easier than others.
@media only screen and (-webkit-min-device-pixel-ratio: 1.8), only screen and (-o-min-device-pixel-ratio: 18/10), only screen and (min-resolution: 180dpi) { @-ms-viewport{ width:960px; } } <br>
Server Timeout in WebDirect
In WebDirect, DayBack submits a request using Perform Script On Server (PSOS) to modify an event. Technically, this is asynchronous, but the client needs to know when the update has been completed in order to properly update the event on the calendar. This check is done in the "Process Web Direct Log - DayBack" script.
If your server is taking a bit longer to process these event updates, you may receive an error, or won't see the "Saved" confirmation after modifying an event. On line 17 of the script, there is an If statement that limits the check to 20 retries. If you're running into this issue, you could try increasing this value to retry a bit more.
If you're needing to increase this value a lot, it's likely that there are script triggers on your file that are unnecessarily running for every PSOS request. This causes these requests to be very slow because each one starts its own session, which is like opening the file. You can increase the performance of these PSOS requests by escaping any unnecessary script steps when run on server using: Patterncount ( Get ( ApplicationVersion ) ; “Server” )