Hello,
I am about to purchase DayBack for a client. The file I built for them has two tables with dates we'll be integrating: Tasks and its child table Steps. I was considering creating another child table, Dates, to combine dates from these two tables into a single table to integrate with the DayBack calendar. But upon reviewing your product, I see that I can use each table as a separate source instead. How do we determine which is the best way to go, before spending time on one method vs. the other? I.e. it's hard to test performance in advance, so how would performance differ when using one source vs. two? And is using two sources the best way to filter viewing each of the sources of dates separately; or if we combine into a single Dates table, is there a better/faster filter to use? Clearly adding a new Dates table would involve more programming of the current file; would it then involve significantly less time integrating, since there is only one source to integrate? In addition, I see from the sample data that clicking on a ToDo record in the calendar behaves differently than clicking on an Event record (opening up a different record layout; not opening up a popover). Is this necessarily the case or can ToDos open popovers just as Events do? How does clicking on other sources behave? Any insight is appreciated. Thank you!

Good questions, Dina!

You're correct that you could do this as one data source (with a new table) or two (using the tables you have). Overall, I think two is the way to go but I'll flesh out my reasons in answer to your questions below...

it's hard to test performance in advance, so how would performance differ when using one source vs. two?

With two sources DayBack will make two find requests n your FileMaker solution and by default do those as PSOS scripts on your server. So that probably is a bit more overhead than one source. But that total volume of data returned in either case will be the same so I don't think I'd let the # of find requests be the deciding factor here.

More relevant, I think is that of you make a single dates table you may have a lot of related info in there (the name of the task, for example) that would otherwise be local. Retrieving that data (or worse yet, filtering for it) would likely show up as a slow down. So to the degree that multiple sources keep more of the data local to the table you're searching in... two sources would likely be faster.

And is using two sources the best way to filter viewing each of the sources of dates separately; or if we combine into a single Dates table, is there a better/faster filter to use?

You can turn sources on or off as if they were their own filters, so if you wanted to just see tasks instead of task steps, it would be somewhat easier with tasks and steps being separate sources. If they're were in one dates table you'd need to create your own filter for Tasks vs Steps. Making your own filter is not hard--and you'll likely end up making some anyway--but why make the extra work.

Clearly adding a new Dates table would involve more programming of the current file; would it then involve significantly less time integrating, since there is only one source to integrate?

Integrating an additional source doesn't take that long, especially once you've done one. Nowhere near as much time as making a new consolidation table with all the consequences that could have in other aspects of your solution that need dates.

In addition, I see from the sample data that clicking on a ToDo record in the calendar behaves differently than clicking on an Event record (opening up a different record layout; not opening up a popover). Is this necessarily the case or can ToDos open popovers just as Events do?

Right. We have ToDos behave differently so you can see what using a FileMaker layout looks like vs using a popover "in" the calendar. The decision to use your own layout or a calendar popover can be made on a source-by-source basis and is done in the script "Load Source Settings at Startup --- Describe Your Sources Here ---": at line 27 for source no 1 (sample events) and at line 62 for source no 1 (ToDos). When you make a branch in that script for your own source (or just use source 2 for your Steps instead of ToDos) you can decide how you'd like your source to behave.

While you're playing with DayBack, and the ToDos are still set to open a FileMaker layout, turn on the script debugger and click on a ToDo: you'll see that DayBack is just calling a FileMaker script that you can modify to get your own behaviors. =)

Thanks again for the questions. I hope this helps.

Fantastic! This is very informative and helpful. Thank you!!