DayBackForFileMaker

Speed

DayBackForFileMaker.Speed History

Hide minor edits - Show changes to output

May 19, 2023, at 04:44 PM by 192.88.134.15 -
May 19, 2023, at 04:23 PM by 192.88.134.15 -
Changed line 25 from:
%center% %width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png | https://www.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png]]
to:
%center% %width=440% [[https://archive.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png | https://archive.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png]]
March 16, 2018, at 01:37 AM by KC Embrey - Fixed bullet points
Changed lines 3-24 from:
'''�''' Delete or rename any "Source No X" layouts you're not using. So if you're only using 1 source, delete the layout Source No 2 or edit the name by replacing "No" with "Was" as in "Source WAS 2".

'''�''' Show only one source at a time. Anything that shows more records at the same time asks FMP to work harder.

'''�''' Understand how Perform Script on Server (PSOS) works and use it if it makes sense for you. More here: [[PSOS | PSOS in DayBack]].

'''�''' Mapping the event summary (DBk_EventSummaryCalc ) to a lot of related fields can slow things down a bit. Try using a regular text field (without carriage returns) for your summary instead. And the shorter the contents of this field, the better. The same applied to the fields mapped in the field DBk_WebViewerSource: using related fields here is cool, but it costs some speed.

'''�''' Make sure the fields you're mapping to on the "Source No X" layouts are indexed. Again, not always possible, but it helps.

'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around to different machines / users, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:

-> Check FileMaker Version
-> Write test -- is file editable?
-> Check System Formats (test disabling this script and quitting/reopening FileMaker. If everything looks good, then remove this from Upon Opening.)

'''�''' You may want to show only All Day events on the month view (since that view has the potential to show the most records, it is potentially the slowest as well). You can restrict the month view in this way pretty easily:

-> Edit the script "Event Find" and find the comment "Apply any user-specified filters to the found set".

-> Right *before* that comment add the following lines:
to:
-> - Delete or rename any "Source No X" layouts you're not using. So if you're only using 1 source, delete the layout Source No 2 or edit the name by replacing "No" with "Was" as in "Source WAS 2".

-> - Show only one source at a time. Anything that shows more records at the same time asks FMP to work harder.

-> - Understand how Perform Script on Server (PSOS) works and use it if it makes sense for you. More here: [[PSOS | PSOS in DayBack]].

-> - Mapping the event summary (DBk_EventSummaryCalc ) to a lot of related fields can slow things down a bit. Try using a regular text field (without carriage returns) for your summary instead. And the shorter the contents of this field, the better. The same applied to the fields mapped in the field DBk_WebViewerSource: using related fields here is cool, but it costs some speed.

-> - Make sure the fields you're mapping to on the "Source No X" layouts are indexed. Again, not always possible, but it helps.

-> - Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around to different machines / users, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:

--> *Check FileMaker Version
--> *Write test -- is file editable?
--> *Check System Formats (test disabling this script and quitting/reopening FileMaker. If everything looks good, then remove this from Upon Opening.)

-> - You may want to show only All Day events on the month view (since that view has the potential to show the most records, it is potentially the slowest as well). You can restrict the month view in this way pretty easily:

--> Edit the script "Event Find" and find the comment "Apply any user-specified filters to the found set".

--> Right *before* that comment add the following lines:
Changed lines 27-34 from:
-> That will leave only the all day events.

'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [[https://network-tools.com/ | Ping]] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we think you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.

'''�''' The "List" views for Day and Week are somewhat faster.

'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [[Filters | here]].
to:
--> That will leave only the all day events.

-> - If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [[https://network-tools.com/ | Ping]] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we think you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.

-> - The "List" views for Day and Week are somewhat faster.

-> - Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [[Filters | here]].
Changed line 41 from:
-> FileMaker is very sensitive to record size (sometimes called record "width") and if you have more than a paragraph of text coming back for each record in the contents of the "DBk_WebViewerSource" field you may be slowing things down. Try reducing the amount of text turned here by removing fields from that calc or trimming the result using Left()
to:
-> - FileMaker is very sensitive to record size (sometimes called record "width") and if you have more than a paragraph of text coming back for each record in the contents of the "DBk_WebViewerSource" field you may be slowing things down. Try reducing the amount of text turned here by removing fields from that calc or trimming the result using Left()
November 13, 2017, at 07:38 PM by 192.88.134.15 -
Changed line 41 from:
-> FileMaker is very sensitive to record size (sometimes called record "width") and if you have more than a paragraph of text coming back for each record in the contents of the "DBk_WebViewerSource" field you may be slowing things down. Try reducing the amount of text turned here but removing fields from that calc or trimming the result using Left()
to:
-> FileMaker is very sensitive to record size (sometimes called record "width") and if you have more than a paragraph of text coming back for each record in the contents of the "DBk_WebViewerSource" field you may be slowing things down. Try reducing the amount of text turned here by removing fields from that calc or trimming the result using Left()
September 11, 2017, at 10:08 PM by KC Embrey - added a word to make the sentence make sense
Changed line 29 from:
'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [[https://network-tools.com/ | Ping]] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.
to:
'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [[https://network-tools.com/ | Ping]] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we think you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.
April 26, 2016, at 05:03 PM by 192.88.134.15 -
Changed lines 33-43 from:
'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [[Filters | here]].
to:
'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [[Filters | here]].

!! I see "Summarizing" when loading the calendar

If you see "Summarizing Field "DBk_WebViewerEventData" that tells you a couple things you may want to change about your setup:

-> - If you're running from FileMaker Server and have [[PSOS]] turned on (it's on by default), seeing this dialog tells you that the payload of events coming back from the server was too large for PSOS to process and the find request is now being done locally. To speed this up you want to reduce the size of the payload by a) [[filters | pre-filtering]] the calendar so you're showing fewer records and/or b) reducing the size of each record.

-> FileMaker is very sensitive to record size (sometimes called record "width") and if you have more than a paragraph of text coming back for each record in the contents of the "DBk_WebViewerSource" field you may be slowing things down. Try reducing the amount of text turned here but removing fields from that calc or trimming the result using Left()

-> - If you're not running this from FileMaker Server you simply have a large payload and/or a slow client machine. You may want to reduce the payload size as suggested in the paragraph above or try hosting DayBack from FileMaker Server
.
Deleted lines 0-11:
!! Timing the calendar

Note that the calendar has some instrumentation built in to help you measure speed and see if you're making things faster (or slower).

Run the script "Timer ON" and this will cause two dialogs to come up when the calendar is refreshed. One after the data is loaded, and another after the calendar is redrawn.

Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.

Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.

''To time your own scripts check out the Timer comments in the script "Insert Events File Into Calendar" to see how we place these calls within a script we want to time.''

Changed lines 7-12 from:
'''�''' Mapping the event summary to a [[MultiLineEvents | multi-line calc]] can slow things down a bit, especially if the calc is unstored. Try using a regular text field (without carriage returns) for your summary instead. And the shorter the contents of this field, the better.

'''�''' If you're frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh
the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectExit. You'll now need to press "enter" (or click out of the field) after selecting your filter items so you may want to add a small note to that effect below the filter fields in question. (note that OnObjectExit is now the default as of [[version history | version]] 7.25)

'''�''' Make sure the fields you're mapping to on the "Source No X" layouts are indexed
.
to:
'''�''' Understand how Perform Script on Server (PSOS) works and use it if it makes sense for you. More here: [[PSOS | PSOS in DayBack]].

'''�''' Mapping the event summary
(DBk_EventSummaryCalc ) to a lot of related fields can slow things down a bit. Try using a regular text field (without carriage returns) for your summary instead. And the shorter the contents of this field, the better. The same applied to the fields mapped in the field DBk_WebViewerSource: using related fields here is cool, but it costs some speed.

'''�''' Make sure the fields you're mapping to on the "Source No X" layouts are indexed. Again, not always possible, but it helps.
Changed lines 17-18 from:
to:
-> Check System Formats (test disabling this script and quitting/reopening FileMaker. If everything looks good, then remove this from Upon Opening.)
Changed lines 21-34 from:
-> Edit the script "Write FileMaker Source to Variable" and find the comment "Nothing Found?".

-> Right *before* that comment add the
following:

--> If [ $$sc_Mode = "Month" ]\\
Enter Find Mode [
]\\
Go to Object [ Object Name: "SourceTimeStart" ]\\
Insert Calculated Result [ "*" ]\\
[ Select ]\\
Omit Record Constrain Found Set [ ]\\
End If\\
#\\
#Nothing found?

to:
-> Edit the script "Event Find" and find the comment "Apply any user-specified filters to the found set".

-> Right *before* that comment add the
following lines:

%center% %width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png | https://www.seedcode.com/rootimages/stikipad/dayback/alldaymonth.png]]
Changed lines 31-33 from:
'''�''' The "simple" views for Day and Week are somewhat faster. Select these on the Settings tab in the calendar sidebar. More here: [[Simple Views]].

'''�''' If you're entering a lot of events at the same time, you may not want the calendar to refresh after each event is entered. To achieve this simply close the Event Detail window after you've edited the event: the event will still be committed to FileMaker, but since the calendar hasn't refreshed the event won't show up and you can quickly create the next one. Almost any subsequent action will refresh the calendar (switching days, views, etc) and you can always refresh it manually
.
to:
'''�''' The "List" views for Day and Week are somewhat faster.
May 31, 2014, at 10:11 PM by 50.132.85.96 -
Changed line 21 from:
'''�''' If you're frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectExit. You'll now need to press "enter" (or click out of the field) after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
to:
'''�''' If you're frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectExit. You'll now need to press "enter" (or click out of the field) after selecting your filter items so you may want to add a small note to that effect below the filter fields in question. (note that OnObjectExit is now the default as of [[version history | version]] 7.25)
May 30, 2014, at 05:16 PM by 107.77.75.22 -
Changed line 21 from:
'''�''' If you're frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectSave. You'll now need to press "enter" after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
to:
'''�''' If you're frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectExit. You'll now need to press "enter" (or click out of the field) after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
January 30, 2014, at 03:31 AM by 50.132.84.245 -
Changed lines 9-11 from:
''Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.''

To time your own scripts check out the Timer comments in the script "Insert Events File Into Calendar" to see how we place these calls within a script we want to time.
to:
Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.

''To time your own scripts check out the Timer comments in the script "Insert Events File Into Calendar" to see how we place these calls within a script we want to time.''
January 30, 2014, at 03:31 AM by 50.132.84.245 -
Added lines 1-12:
!! Timing the calendar

Note that the calendar has some instrumentation built in to help you measure speed and see if you're making things faster (or slower).

Run the script "Timer ON" and this will cause two dialogs to come up when the calendar is refreshed. One after the data is loaded, and another after the calendar is redrawn.

Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.

''Times displayed here aren't much use on their own, but are great when comparing two versions of a script: 1) click refresh, 2) notice the times, 3) change your script, 4) refresh again and notice the times.''

To time your own scripts check out the Timer comments in the script "Insert Events File Into Calendar" to see how we place these calls within a script we want to time.

Deleted line 13:
February 25, 2013, at 03:51 AM by 98.245.113.231 -
Changed lines 14-15 from:
'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around to different machines / usesr, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:
to:
'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around to different machines / users, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:
April 21, 2012, at 10:44 AM by 93.95.107.10 -
April 21, 2012, at 10:43 AM by 93.95.107.10 -
Changed lines 8-11 from:
'''�''' Mapping the event summary to a [[MultiLineEvents | multi-line calc]] can slow things down a bit, especially if the calc is unstored. Try using a regular text field (without carriage returns) for your summary instead.

'''�''' If you'r
frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectSave. You'll now need to press "enter" after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
to:
'''�''' Mapping the event summary to a [[MultiLineEvents | multi-line calc]] can slow things down a bit, especially if the calc is unstored. Try using a regular text field (without carriage returns) for your summary instead. And the shorter the contents of this field, the better.

'''�''' If you're
frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectSave. You'll now need to press "enter" after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
Changed lines 14-15 from:
'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around or having users from the EU coming in, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:
to:
'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around to different machines / usesr, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:
Changed lines 18-19 from:
-> Check system formats
to:
March 21, 2012, at 10:58 PM by 50.132.84.245 -
Changed lines 6-9 from:
'''�''' Show only one source at a time; when multiple sources are on screen at the same time the calendar sorts them against each other to see which events come first. This take time.

'''�''' If you're not [[AddingFields | showing related fields on the day view]], turn off the "refresh" at the end of the script "Go to Calendar Tab ( Tab Name )"

to:
'''�''' Show only one source at a time. Anything that shows more records at the same time asks FMP to work harder.
Added lines 10-11:
'''�''' If you'r frequently selecting multiple resource filters (or any other filter formatted as a checkbox) you'll see that we refresh the calendar after each selection. You can change this by editing the filter field in layout mode and moving the script trigger from OnObjectModify to OnObjectSave. You'll now need to press "enter" after selecting your filter items so you may want to add a small note to that effect below the filter fields in question.
Changed lines 14-15 from:
''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash".
to:
'''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash". If you're not going to be moving the solution around or having users from the EU coming in, you can disable a few routines in the Upon Opening routine to speed things up a little. Disable the steps in Upon Opening that follow these comments:

-> Check FileMaker Version
-> Write test -- is file editable?
-> Check system formats

Added lines 14-15:
''�''' Speed up the launch by Editing the "Upon Opening" script and disabling the perform of the subscript "Splash".
Added lines 34-37:
'''�''' The "simple" views for Day and Week are somewhat faster. Select these on the Settings tab in the calendar sidebar. More here: [[Simple Views]].

'''�''' If you're entering a lot of events at the same time, you may not want the calendar to refresh after each event is entered. To achieve this simply close the Event Detail window after you've edited the event: the event will still be committed to FileMaker, but since the calendar hasn't refreshed the event won't show up and you can quickly create the next one. Almost any subsequent action will refresh the calendar (switching days, views, etc) and you can always refresh it manually.

July 29, 2010, at 03:44 PM by 76.22.123.157 -
Changed lines 32-33 from:
'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [https://network-tools.com/ | Ping] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.
'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [Filtrs | here].
to:
'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [[https://network-tools.com/ | Ping]] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.

'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [[Filters | here]].
July 29, 2010, at 03:43 PM by 76.22.123.157 -
Added lines 12-13:
'''�''' Make sure the fields you're mapping to on the "Source No X" layouts are indexed.
Added lines 31-33:

'''�''' If your server is not on the same physical network as your FileMaker client, there could be an undue amount of latency between them slowing things down. %newwin% [https://network-tools.com/ | Ping] your FileMaker Server to check this: the results really depend on what kinds of speed you can tolerate, but we you'll likely be happy with pings under 50-70ms. Anything above that and you may want to start asking some of the FileMaker Server hosting providers for test pings to their servers to see if they'd be faster than what you have.
'''�''' Finally, the calendar works harder when it has more work to do, so filtering or pre-filtering to show only the relevant records can speed things up a lot. More on filtering [Filtrs | here].
February 18, 2010, at 05:01 PM by 137.159.253.133 -
Changed line 18 from:
--> If ( $$sc_Mode = "Month" )\\
to:
--> If [ $$sc_Mode = "Month" ]\\
(855) SEEDCODE
[email protected]
Follow us: