On May 6, 2:04 pm, Martin Trautmann <t-...@[EMAIL PROTECTED]
> wrote:
> On Tue, 6 May 2008 13:32:48 -0700 (PDT), d-42 wrote:
> > > > 2) Why use an external script? Why not localize it all in one
file.
>
> > > This would slow down operations even more. It would complicate
backup
> > > schemes. It would slow down data dumps etc.
>
> > It would do no such thing.
>
> I misunderstood your answer - I thought your suggestion was to merge all
> different tables within a single file.
Hell no. :)
> Ok, maybe you are right that a single master file could to the job which
> does take all the external data via layouts and related fields.
NO! YOU DO NOT NEED TO WORK VIA RELATED FIELDS!!
That would be slow.
Define a table occurrence in the relation****ps graph for your external
table, and then define a layout that uses that table occurrence. You
don't need to define a relation****p to do this.
> Actually, I never tried this approach for this task here. I always
> prefered to keep things independently and standalone. But I doubt that
> calling the operations one step further away would speed up things. All
> my former experience has proven the opposit.
Working on an external table defined as I did above is the same speed
as working on it in its own file. At the same time, a big performance
hit is incurred in FM9 when you hop from window to window. (much
bigger than was incurred in FM6) so not doing it is both possible in
FM9 and highly desireable.
Additionally, hopping around in FM9 does NOT commit records. It did in
FM6. Not committing the records and hopping around, especially between
files, can lead to MASSIVE slowdown in FM7+. If you make changes to a
record and then hop to another window, the record you left behind
still has the record locked and the changes have not be committed.
> Switching files, layouts may add a speed penalty. But that's perfectly
> minor to the operation itself. Doing a search or a sort on related
> records instead of working within this table itself never was faster,
> but many times was much, much slower (as indicated e.g. within the
> described AND search).
You were doing it on 'related' records. It shouldn't have beeen done
that way.
> I don't know whether this malfunction is gone in FMP 9.
> But FMP told me it was resorting a certain amount of records, continuing
> in negative numbers, even if the only active window had a sorted subset
> only. Usually it may have some related records on the layout which might
> trigger sorting of related records. I did not find out the logic behind
> yet. You don't know this behavior? You never saw sorting on negative
> record counts?
Can't say that I have. Although I'm very careful to minimize my use of
sorts because sorting is one of the slowest operations you can do in a
database.
> > You seem to have taken the least optimal route at multiple points, I
> > can't help but suspect that maybe, just maybe, your performance hit
is
> > still design related. That its taking longer to sort than it has too,
> > That your freezewindow is having no positive effect because you are
> > window hopping, that your applescript is taking far more time than
you
> > think...that maybe there is some goofy summary field calculations
that
> > are dragging your print performance down the tubes...
>
> All of this does sound like minor speed improvements only.
Maybe. Maybe not. You've got a script that takes 12x longer than it
used to. Its worth it to dig deep. Record locking issues alone could
account for it.
> > I'm also curious, have you tried running your solution on Windows?
>
> No, since Win does not offer AppleScript nor integrated PDF creation.
It needs neither.
Applescript as I said is not needed; you can name your files directly
from within filemaker. And FM9 sup****ts PDF creation under both
Windows and OSX. Its a built in feature of filemaker, not the OS.
Hmmm.... How are you generating your PDFs any way? Are you "printing"
them and using the OSX's 'save as pdf' feature? Or are you using
Filemaker's built in PDF engine accessed via the Filemaker Script
step: "Save Records as PDF" ?
You should try "Save Records as PDF" if you haven't.
> > That might also be instructive. Also, what mac platform are you
> > running all this stuff on? G4? G5? Core2Duo?
>
> G4, 800 MHz, 1 1/8 GB RAM, MacOSX 10.4
Thanks. At least we know we have the option of throwing more modern
hardware at the problem if all else fails. By modern standards that's
a pretty slow machine.
-cheers,
Dave
|
