Summary Dialog Keeps Appearing

[fperugini]

Greetings All,

I have a TimeCard Layout which includes a summary field. This summary field calculates the total of the users time entered for the current week.

This is being used company wide for 30-40 users. Some of our users complain that every time they add a new time entry, the "Summarizing..." dialog appears and has to go through all the records, and they have to wait.

For most users, this "Summarizing..." dialog only appears the first time the layout is display, but not thereafter. Why would this occur on some computers and not others.

They are all running the same version of FileMaker (v6), and OS (Win2K). The only difference appears to be the processor type and memory configurations. The users that complain are still on P2 computers with either 256MB or 384MB of RAM, whereas the others are on P3's and P4's with similar amounts of RAM.

Does anyone have an explanation for this phenomenon?

-Frank

[Lee Smith]

Hi Frank,

Similar questions have come up from time to time on other FileMaker list that I belong to (probably here too, but I can't remember) concerning how much Ram FileMaker can utilize. I believe the number is 40, 42 maybe 45 megs. Anyway, anything above that has no affect on FileMaker's speed. However, the speed at which FileMaker can write and access data from your Hard Drive has a lot to do with performance. So, the cleanest and fastest Drive will win out.

If you were on a Mac, I would recommend rebuilding the desktop, tossing preference files, and defragmentizing (is that a word) the hard drive to maximize your HD performance. The HD speed itself has no fix, only replacement.

HTH

Lee

[LaRetta]

Hi Frank,

Some of our users complain that every time they add a new time entry, the "Summarizing..." dialog appears and has to go through all the records, and they have to wait.

Go through ALL the records? Hmmmm ... I don't know your structure or what you are currently summarizing on, but something else which might help ... you can probably cut down on the processor requirements. Summaries are notorious resource hogs.

Since a User only cares about seeing their summary of time worked for the weekk while entering their data, you can narrow or find only that staff's data to 'summarize'.

Create a calculation called cStaffWeekKey (text, index ON) with: WeekofYear(Date) & " " & StaffName

Create a self-join relationship (called StaffWeek) joining this field to itself. Then create a calculation (number) with: Sum(StaffWeek::HoursWorked)

Place this calculation on the layout. By summarizing only the staff's week records, it should speed up. If you're timecard solution is based upon anything other than WeekOfYear, you may have to adjust your calculation for your key field. We'd be happy to help you if that's the case. This should 'summarize' much more quickly than a Summary field.

There are other tricks in speeding up Summary displays. What is your Summary field based upon? Are you performing a find and layout switch? A Summary field on the same layout with data-entry may be worth reconsidering. If you could explain more, we may have more suggestions for you.

Cheers,

LaRetta

[fperugini]

LaRetta,

Thank you for the information in your post. Sounds like you have done this before...

I am already doing some of what you suggested, here are the relevent fields:

gUserId Global(Text)

TaskDate Date Indexed

UserAndWeek Text Indexed

TimeHours Number

TimeMinutes Number

cHourMinutes Calculation(Number) = TimeHours + TimeMinutes

cCurrentWeekEntry Calculation(Number) Unstored calculation = If( UserAndWeek = gUserAndWeek, cHourMinutes , 0 )

sCurrentWeekTotal Summary(Number) = Total of cCurrentWeekEntry

The difference from what you suggested is that I use of a summary field to show a user's weekly total. Maybe I can try your suggestion of using the self-join relationship and the calculation field to get the total. Do you see any other potential bottlenecks?

-Frank

[LaRetta]

Hi Frank! Bottlenecks? Well, you're already hitting one. Even a small improvement is always worth implementing in a solution - it all adds up. But I think you will see a major improvement.

sCurrentWeekTotal Summary(Number) = Total of cCurrentWeekEntry

The above will calculate every record in your db or found set.

I'm unsure why you use a global to capture the User. You could be using Status(CurrentUserName) in your key. Be sure to have index ON. So your key would be WeekofYear(TaskDate) & " " & Status(CurrentUserName)

I think you can modify my suggestion and it will help quite a bit. Back up first, but then give my suggestion a try on a new layout then switch between the two and give it a test. You can also decrease the number of calcs and standard fields, I think.

cHourMinutes Calculation(Number) = TimeHours + TimeMinutes

Keep this calculation and modify the calc Sum(StaffWeek::HoursWorked) to Sum(StaffWeek::cHourMinutes)

Why do you have a text field UserandWeek? If you determined the 'week' via calc (and you've already captured the UserName via Status(CurrentUserName), this field wouldn't be required. Nor would your global. cCurrentWeekEntry wouldn't be needed either.

LaRetta

[fperugini]

LaRetta said:

I'm unsure why you use a global to capture the User.

I do not use the built-in User, I have implemented a custom scripted authentication scheme.

I agree I may have too many intermediate fields...I was still learning at that point. When I look at it now, it is obvious.

I am going to try some of your suggestions, with the exception of changing gUserId, I think they should help.

-Frank

[LaRetta]

Hi Frank,

Unless your Users switch and use each others computers, the system will always know the current user. You will not be able to use a global in your self-join key because it can't be indexed for the right side. But when a User selects their name (from a pop-up) text field for their current (or new day entry), you can use that field in your key. Users will need to exit the field (commit the record) before the Sum field adds their current entry to the total.

Good luck to you and let us know what you discover, okay?

LaRetta

[fperugini]

LaRetta said: Unless your Users switch and use each others computers...

Yes, some stations are shared amongst employees of different shifts, that's one of the reasons for the custom authentication scheme.

I'll have to try and find a way around the global in the self-join key...

Right now a user does not need to enter his name when adding a new Timecard entry because it already knows who is logged-in.

Thanks again for your time and insight.

-Frank

[LaRetta]

Hi Frank,

Right now a user does not need to enter his name when adding a new Timecard entry because it already knows who is logged-in.

UserAndWeek Text Indexed

Then use the above field for your key instead of the one I suggested. When I saw you used a global, I should have decyphered that you scripted new records. You've even indicated it's indexed so you can join on that field and be in business in no time.

LaRetta

[Vaughan]

"Some of our users complain that every time they add a new time entry, the "Summarizing..." dialog appears and has to go through all the records, and they have to wait."

Summary fields only re-calculate if the field is on the current layout. So make sure the summary field is only on the layout it's really needed.

Also see if you can replace the summary field with a calc field: I saw one case where the data entry screen had a summary field just to display the number of records in the database. Big waste of time. Solutions were to either remove the summary field (it was a useless interface element) or replace it with a calc field using Status(CurrentRecordCount).

[fperugini]

LaRetta,

I made one small change that made all the difference in the world. It was so obvious. When I opened my Timecard module, I was scripting a "Show All Records" step. All I needed to summarize for the user's weekly total was his/her records for that week, which is a very small amount of records. They way I had it, it had to go through all the records needlessly...duh.

I already had everything in place with a self relationship to filter those records, so after the "Show All Records", I added "Show Related Record" using that filter relationship, and now all my problems are gone! I am very happy again.

Thanks for all your help.

-Frank

[Ugo DI LUCA]

Add one step to your script :

If (IsValid(your_filtered_relationship::anyfield)

GoToRelatedRecord

....and eventually

Else

Show Message "There is no record for this week")

This would prevent your users to be stuck with a 0 record found, locked in the dark of your solution. , unless you allow them to use FM Menu for a show All Records.

[fperugini]

Good suggestion Ugo. I missed that in the excitement.

-Frank