Spiral Posted February 21, 2006 Posted February 21, 2006 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 Posted February 21, 2006 Posted February 21, 2006 ... refresh window & flush cached join results? also make sure that your file is actually commiting the records... ~genx
Spiral Posted February 21, 2006 Author Posted February 21, 2006 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 Posted February 21, 2006 Posted February 21, 2006 ... 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 Posted February 22, 2006 Posted February 22, 2006 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 Posted February 22, 2006 Posted February 22, 2006 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
Recommended Posts
This topic is 6865 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now