as far as i know, no, this cant be done.
That's odd cause my client says it's been doing it forever on their FMP5.5 Server when two people are using the same database with FMP6 clients. I can't reproduce though with 2 clients and no server and I'm 100 miles away to check it personally... hmmm...
I've always used an update loop both in FMP 5.5 and in FMP 10 today.
There are ways to keep the update loop fairly unnoticeable by hiding the status bar and other details. Any chance that there was an update loop that is no longer being used?
As in a script? I've looked at all the scripts and there's nothing there and nothing is running that I can tell. The situation is as I described in another post:
1 FMP 5.5 Server
2 FMP 6 clients
The two clients access a file VIA the server. Client 1 just leaves the phonelog layout open on his screen. Client 2 makes changes which appear instantly on client #1's screen when client #2 clicks off entering all the fields of a new record.
This is apparently working now.
I have the same exact phonelog file and running it without a server and just accessing the file directly doesn't work.
When you open it, it does run this script:
Go to Layout ["Main List"]
Perform Find [Restore, Replace Found Set]
Sort [Restore, No Dialog]
Enter Browse Mode 
But that's it - no loop - and all that does is just throws ya onto the main screen...
I just did a quickie test with FMP 5.5. The conditions are NOT identical, but maybe this can trigger an answer.
The file is being hosted by FMP 5.5 (peer to peer)
I located a record from a client machine.
I located the same record on the host machine.
On the client, I typed text into a field.
Once I clicked the layout background, which commits the record, I instantly saw the update on the Host machine.
That suggests a possible explanation: Are the users leaving the cursor in a field and thus not seeing the update because it hasn't yet been committed?
The update loop that I use is needed because new records are being added to a found set and thus I have a loop triggering a new find every few seconds. If a record that is already visible on both machines is being modified, you should see the update on both.
Another possible explanation:
Are both users actually seeing the same record? Could one user be viewing a duplicate record?
Duplicate Record has messed me up more than once because users can so easily generate one or more records with identical data with a simple keyboard shortcut.
It's not working in that manner - there is a layout of the top/body/bottom and the body is a single line with several fields horizontally sorted by "today's date". When viewed, you see the entire screen with the 'body' taking up quite a bit of the screen of course. As records are added on the one machine, new ones pop up automatically on the machine just sitting there looking at "today" which is what the first script is doing, setting the machine to pre-sort "Today".
So new day, nothing on either screens - create 5 new lines (5 records on the one machine) and as the person inputting the new line of data constituting the new record clicks off the line on the background committing them all, it appears on the oher machine just sitting there.
If that still works with your scenario, and only with the 5.5 server running and not two clients just assesing the data file, then this would be a server setting pushing new data?
Also, thanks for checking this out - Without a 5.5 server, I'm running blind at the moment. :)
Here's some images to help illustrate:
START OF NEW DAY ON BOTH SCREENS:
INSERTION OF 6 NEW CALLS (and NEW CALL button has no script to trigger any type of refresh)
These all SHOULD show up as they get done one by one on the other screen but they don't - that screen on the new converted 9
files just stays blank - apparently on the 5.5 server driven 6 clients, it DOES update at the same time...
Let's clarify a very, very important detail here:
What user #2 is NOT seeing is the appearance of a new record created on this list view layout?
That's what I interpret from your screen shots.
If so, then as far as I know, this won't work and never worked without some kind of update action.
If the same record is visible on both clients, then an update performed on data in a field on one machine will automatically appear on the screen of both machines. If you add a NEW record matching the find criteria used to originally pull up your record set, then it will, NOT automatically appear on the other client's machine unless you perform the find again to pull it up.
Thus if the phone number for Call 6 is changed from 555-1212 to 555-1213, the change should appear on both screens. If a user creates a new record, Call #7, then no other user will see the record for Call #7 until they perform the find for today's records all over again.
Example from one of my own systems:
We have a Point of Sale type system where one user fills out an invoice record and a second user (the cashier) prints the invoices and handles the money that changes hands. When the first user finishing inputting data into the record, they click a button that changes a text field from "pending" to "Ready for Cashier". The cashiers keep a layout listing all "Ready for Cashier" tags that they use to select a record to print. That layout has a continuous loop that Performs a find for all records with "Ready for Cashier" every 2 seconds. If that loop didn't execute, then no invoices would appear on their screen after the status changed to "Ready...."
I originally listed these "ready" records in a portal and had to use a loop to update a field in the relationship in much the same fashion.
>Let's clarify a very, very important detail here:
>What user #2 is NOT seeing is the appearance of a new record created on this list view layout?
Correct. Apparently when user #1 does a NEW RECORD, the new record appears and they enter in the line. When they click off the line, the new line appears on user #2's screen. Now that's what I've been told - site is 100 miles away and I may need to just go in to fix a 10 second issue which according to them, this is the behavior so all I can think of is some force update function of the 5.5 Server, not the clients...
> If so, then as far as I know, this won't work and never worked without some kind of update action.
Agreed - has me scratching my head.
>If the same record is visible on both clients, then an update performed on data in a field on one machine will automatically appear on the screen of both machines. If you add a
>NEW record matching the find criteria used to originally pull up your record set, then it will, NOT automatically appear on the other client's machine unless you perform the find
>again to pull it up.
True which would seemingly mean there's some sort of background script running on client #2 to force update every 10 secs or so but that's not it - no script is there and that would lock them out of doing anything else so again, points to some server setting for dynamic forced updates of data... seems trivial but I'm tending to agree w/you and the silence of everyone else and on other forums to explain the lack of this working. Maybe my clients are /confused/ :D
>Thus if the phone number for Call 6 is changed from 555-1212 to 555-1213, the change should appear on both screens. If a user creates a new record, Call #7, then no other user
>will see the record for Call #7 until they perform the find for today's records all over again.
True - this happens client <-> client.
Sounds like a good plan of attack.
"and the silence of everyone else and on other forums to explain the lack of this working"
If by other forums, you mean the Using Server Forum here at Filemaker, then that forum seems to be neglected a lot. Posts to that thread can languish for days without any response. I know TSGal has been trying to pick up the slack, (Thank you TSGal!), but one of my posts has now been there for half a week with no response and it's not alone.
Although I cannot duplicate the problem, it very well could be a problem. What is causing this? I don't know. Sometimes customers are mistaken, but I've learned (the hard way) to never doubt a customer. I can only tell you what I have done to try and duplicate the problem.
Perhaps it is a conversion issue from FileMaker Pro 6 to FileMaker Pro 9. I have enough machines and servers here to test the problem with FileMaker Pro 9, so if you want to send in the database file, I will do my best to try and duplicate the problem here. I have sent you a private message (top of this screen - right side - X Messages) with instructions where to send the database file.
I am almost caught up on the Server board. It sounds like I missed one of your posts, so if you have the link, let me know, and I'll revisit the post because there may be others in a group that are still unanswered.
You've responded to my post (Windows Server CAL) since my last post to this thread. Thank you.
Be advised that Pstone has identical threads for this question in both using server and using filemaker forums. Since our responses haven't been perfectly identical, this has confused him a bit, but I think we've cleared most of that up now.
Just incase no one sees the server post. I am the client and have tested with a brand new log on the 9 server and it works fine. It is just the converted logs that do not work. Hope this helps.
lol - then I realized what you meant by being the client! heh, yes, this is the case and as you can see, something is up with the conversion - There are no scripts in the pre-converted file and hence no scripts in the converted file - so far as you can see, this has created quite the conundrum!
I'm making this post to wipe a little egg off my face. I've just discovered a way that the "found set" of a client's machine will automatically update, with no scripts or other widgets.
If the client has selected "Show All Records", then the list of visible records will automatically update when a new record is add by a different client. If I omit even one record from the found set, then this doesn't happen.
This might explain the issue described in this thread.
If I hadn't left a table view layout showing all records up on one machine while testing the DB on another, I might not have ever observed this. :smileywink: