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...

Error 102

102 means a "field is missing" so it sounds like DayBack is trying to write your event back to FileMaker but can't find one of the fields it needs. This is probably because one of the fields you've specified in field mapping was renamed or deleted.

Error 103

"Relationship is missing." Double-check to make sure the table occurrence names for your calendar source matches the one you selected in DayBack's settings on your calendar's Calendar Info tab. Your table occurrence may have been renamed.

Error 201

"Field Can't Be Modified." Make sure that all of the fields you mapped in field mapping are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead. (The most common cause of 201 errors is mapping a calculated field to the event Summary. You'll want to make sure the field mapped there is editable.) If you need to map to a calculated field, you'll find instructions for doing that here.

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.

• Since web viewers are rendered as a web page, they have a separate zoom mechanism from FileMaker's zoom. This means you can zoom into the calendar using ctrl+scroll (or + and -) and it will not affect the other FileMaker objects. This is probably the easiest way to get the calendar objects to render at a higher scale without making your Event Detail window look too large.

• You could try increasing the system-wide Windows DPI scaling, keeping in mind that this will have an effect on all apps. Here's a link to instructions on adjusting the Windows DPI scaling: https://technet.microsoft.com/en-us/library/ff629368.aspx?f=255&MSPPError=-2147217396

• You could add the following to your CSS to adjust the zoom for Windows devices with high DPI screens:

@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>

This will only apply to Windows devices with screens showing 180dpi (dots per inch) or higher. You might want to modify the 3 dpi settings (1.8, 18/10, 180dpi) to get the right criteria for when to zoom or not.

For example, on a 40" 4k screen, DayBack looks great by default, so you don't want to resize on that screen. The dpi on this screen is 110.

An 11" 1080p screen has a dpi of 200, so you probably would want to zoom in, but it's going to take some trial and error to get the right number.

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” )