How long does FMS8 take to update indexes?

[1Adam12]

Hi,

I'm trying to figure out if I've got a server bottleneck or if I've got some other issue. I've got a db with about 616K recs that is about 220MB in size. It's FMS8v4 running on an older W2K3 box, 1GB RAM, with dual 1Ghz Xeons and a RAID10 system. This box is targeted for upgrading shortly, so please don't tell me I need some newer hardware. The system CPU monitors never peg, it never runs out of resources, indexing is off, AV scanning is off.

I have a function that loops through a portal that displays the results of a complex, multikey join to the above table and writes a unique ID into a temporary printsession field. Then, I call a process that queries the above db for records with that printsession value for a report.

Somewhere in the last few months, this script is failing because it can't find any matching records. I've nuked the indexes, rebuilt the file, tested locally. If, after a little bit I do a manual find for the last printsession value, I get the records.

Using the dbs from the client side are all fast, no interface lags and users are all happy. Ideas? Does anyone know exactly how frequently FMS does index updates? Many thanks.

-A

[Steven H. Blackwell]

1 GB RAM probably is nowhere near enough. What are you cache flush settings? How much RAM is reserved for cache?

Steven

[Genx]

What version of FM client and server are you running? I experienced index issues with v2 -- if any of your clients are running this it might be screwing it all over.

[xochi]

That's a really good point -- one client may be using an old version. Is there a way to check the version # in a login script and pop an error? "Sorry, please upgrade to 8v4 before continuing!"

[Genx]

Get ( ApplicationVersion ) -- I think that's it, don't have FM open, but if it doesn't work just look in help for the real get function.

It will return something like "ProAdvanced 8.0v3"

[Steven H. Blackwell]

The crux of the problem is the interaction between the Server version and the client version.

Be sure that the client version is either 8.0v3 or 8.5v1 and that the Server version is either 8.0v3 or 8.0v4.

Steven

[1Adam12]

Clients are 8.5v1, 8.5 Adv v1 for me. DB cache is set to max on the server, ~233MB. I pulled a set of the files off the server and ran the process locally on my laptop in just 8.5v1 Adv client and it still borked. I removed 75% of the records, so it was down to about 137K recs, watched as it compacted itself, then did a recover, set index for the field to 'none, automatic' and it still fails.

[1Adam12]

server is 8v4 as listed in my orig post.

[Ender]

Maybe it's not the indexes, but a problem with the script, the relationships, or the data. If you could post an example file illustrating the problem it would help narrow it down.

[1Adam12]

i've attached a pdf of the script. i think the relationships are ok as the part that tags the record set with the printsession variable works fine and the records show the resulting set value. i'll try to come up with a schema snapshot to illustrate more.

Print_Snapshot.pdf

[Genx]

Is this field a global?

Service Docs::printsession

[Ender]

It looks like you're marking the related Service Docs records just for the purpose of printing them. You might instead try:

Go to Related Records [ Show only Related; table: Service Docs; layout: Service Docs Details; New Window ]

Sort Records [ Restore ; No Dialog ]

Print Setup [ Restore; No Dialog ]

Enter Preview Mode [ Pause ]

Print []

Close Window [ Current Window ]

[1Adam12]

that one is not. it's a text field. gPrintSession is a global.

[1Adam12]

i didn't think to try that method with the multi-key join i'm using. method i'm using has always worked...until now anyway. i will test and report. thanks for the insight, ender.

[1Adam12]

i just got one of the macbooks today (not just to throw at this ) and ran a quick test in fmpa 8.5v1 under os x with my test using 137K recs with my original method. this worked without a hitch, repeatedly. i'm wondering how much of the indexing process is cpu bound. my windows laptop is a 1.6Ghz Pentium M with 1GB RAM. This MacBook is 2Ghz Core2. i'm going to see if i can pull the full record set and test.

[1Adam12]

ender, your method seems to work beautifully. i'm going to test more with the full record set. easy to get so focused on one solution that one forgets the other skinning of the cat options!

[Ender]

You'll want to test for the presence of related records prior to the Go to Related Records[] step, otherwise you could end up printing the parent record set. This test can be done like this:

If [ isempty(Service Docs::RecordID) ]

Show Custom Dialog [ "No records to print" ]

Exit Script

End If

...

[1Adam12]

that's a good point. i tested against the full record set and it seems to be working nicely. thanks again!