Me again … If what I am stating sounds confusing, I'm confused.
Obviously I need more understanding … calendar page load is still very slow. Not sure what I'm doing wrong here. I am still referencing three global fields ( Month, Day, Year ) within the "cDateOfFirstPortal" which is within each SQL Select Statement. That has not changed.
I've moved the SQL Select Statement's that were calculating within each field ( 42 of them ) to a "SET FIELD" step within a Script … 42 set fields script steps as instructed.
So, Wim … One Table, One Record … that is may calendar with … 42 fields.
Since I am still very slow … can you restate the global issue with Filemaker again. I have 42 set fields within a script now ( field calculations removed ) … but within each SQL STATEMENT I am still referencing this field "cDateOfFirstPortal" ( which has three global fields within it … Let Statement Above ).
Are you saying that each "Set Field" script step is forcing some "LOAD" on the FM SERVER due to the the fact that I'm referencing this "cDateOfFirstPortal" within each SQL Statement ?? which the global fields resides on the clients machine … which does what again to the FM server
And this is why I have a "SLOW" page load. Yes / No / Maybe ?? :-)
If I change the three global field ( Month, Day, Year ) to three number fields ( since I only have one record ) the calendar will still build. Will I have any issues with more than one user on the calendar ??
1) your calculation seems to include at least one global field and that means that it can only be calculated on the client. And since you are calling it 42 times you are causing a lot of data to flow between the client and the server.
Find a way to set that field as part of a scripted workflow instead of using calculations.
The 3 global fields ( Month, Day, Year ) are set on page load. So I shouldn't need to worry about globals on my calendar … Yes / No ??
Thank you for any insight here, and thank for your previous suggestions.