cache problem. (Novice)

[Spiral]

Hello,

I don't know if this is the right place to post this or not, but here goes...

Specs:

• FM8 Server (v2 update) on a dedicated server(W2K Server).

• Users using FM8 (v2 update) on WINXP SP2.

User workflow:

• User creates new record with script1 on layout1.

• Script opens up 3 additional layouts and each layout creates a new record.

Problem:

Only the user who created the record can see the new record for layout1 AND the 3 additional layouts.

The remaining users can only see the new record in layout1 NOT the later layouts.

Temporary Fix:

We found out that if the user who created the record completely exits Filemaker, the other users’ screens refresh and then they could see the new records on layout 2-4.

We also tried this manually, without any scripts, and the problem still exists. The only way to fix this problem was to have the user exit Filemaker.

Is anyone having similar issues?

I believe it's a cache to disk issue. I've tried adding the "flush cache to disk" script step with no success.

Thank you

[Genx]

... refresh window & flush cached join results? also make sure that your file is actually commiting the records...

~genx

[Spiral]

aflgenx,

I'll try that. As far a commiting the records, the user who actually created the record on layout1 doesn't see the new records for layout 2-4.

Should I use the "Commit Record/Request" line script for each script I use?

[Genx]

... that would be wise... though it may not be necessary it doesnt do any harm... and often solves a few of my annoying problems..

~genx

[Wim Decorte]

Maybe not wise in all circumstances. Depends if you want uncommmitted data?

What if a user is editing a record in one window and that data is not ready to be committed yet? If you run a script that commits data you may be compromising your data integrity. It all depends on the complexity of your solution and about the data integrity rules for the data.

Think about all the circumstances the script could be un under and what the consequences of the commit are in each one before you use it.

[Genx]

Well yes, but in this circumstance all spiral is doing is generating new records with no user input required...

Though what i meant when i said it solved some of my problems was that if for example you are trying to move an id from one table to another for the purpose of a lookup and you fail to commit a record, the fields wont look up, then if you try to go to a related record from that, you face problems.

... But yes, think, always think

~Genx