Multiple client instances issue

[Kris M]

Ok here goes...

I have a solution deployed on server adv with one file that is giving me some concerns.

File 1 has an unstored calc of Get (TotalRecordCount) in a number field called total_record_count with a text box field on layout 1 that references that field.

If client A opens file 1 and goes to layout 1

and

client B opens file 1, and goes to layout 1 both total_record_count and the total in the staus bar match.

If client B creates a new record total_record_count and the status bar count match and show the new record yet client A total_record_count does not show the new record while client A status bar does show the new record created by client B.

Question:

How to conduct an appropriate renewal of client A recordset when client B creates a new record?

Someone suggested that using Count() in a cartesian join would solve this.. Can anyone explain how or offer a different solution?

Thanks,

Kris M

[LaRetta]

Hi Kris,

"File 1 has an unstored calc of Get (TotalRecordCount) in a number field called total_record_count with a text box field on layout 1 that references that field."

Take that unstored calculation (be sure it is a CALCULATION and not a standard field with auto-enter calculation on it) and just place that unstored calculation directly on the layout. It will update automatically for every User. :wink2:

[Kris M]

I have already done that per my first post and it is the reason that i have created this thread. Seems that the total count in the status bar and the Get total record count unstored calc type field have two different values when they should have the same value.

[LaRetta]

File 1 has an unstored calc of Get (TotalRecordCount) in a number field called total_record_count with a text box field on layout 1 that references that field.

This says that you created an unstored calculation and then created ANOTHER field called total_record_count out of it ... and placed THAT field on the layout. It will never refresh because a standard field cannot refresh when it is based upon a Get() function such as Get ( TotalRecordCount ).

If you indeed instead have the unstored calculation on the layout and it is displaying a different record count, then it is probably one of two things: 1) it is based upon a different table occurrence than the layout or 2) your file is corrupt.

So things to check: 1) It is indeed the unstored calculation on the layout (and you've verified in the field's storage options that the calculation is checked as 'do not store' and then 2) double-click the field on the layout and check the table occurrence name assigned to it and then check Layout > Layout Setup and make sure it is based upon the same TO as the layout.

[Kris M]

i guess i failed to make myself clear. Their is only one calc field and it is on the layout

[Kris M]

just to be crystal clear....

file 1 has ONE table and table 1 has ONE unstored calc field called total_record_count that is of calc data type and = Get (TotalRecordCount)

[LaRetta]

It didn't take two posts to make your point. I can only go by what you type.

"with a text box field on layout 1 that references that field. "

Again, this implies that you have a text field which references this unstored calc. If that is the case then the text field will NOT refresh.

There was more to my post than discussing the calc field itself. Did you read past the point of my irritating you about the calc? Nevertheless, I'll go by what you are making crystal clear - twice ... that only the unstored calculation is on the layout (regardless of your words). And that you have verified that it is unstored (even though you haven't verified it) and you have verified that it is based upon the same table occurrence (although you haven't verified it) as the layout (and not a filtered TO).

Simply: An unstored calculation with Get ( TotalRecordCount ) will change whenever ANY user adds a record. Your tone (from your very first response) hasn't been pleasant for me to want to help you. Others can take it from here, if they so wish. I'm done.

[Kris M]

I am sorry that you got upset. It was not my intention. I just wanted to make the issue as clear as possible. The issues you mentioned were verifed even though i did not explicitly say so.

[LaRetta]

Then if you can, it would help to see the file. You don't need a cartesian - it should be working. Has the file ever crashed on you?

[LaRetta]

Ya know ... an unstored calculation won't refresh by itself. Something - anything needs to happen to refresh the screen. If you are viewing the status area AND the unstored calc, it may appear that the unstored calc will not refresh when, in fact, it will ... the calc will refresh when calcs do. Could that be the confusion you are seeing? Unless the calc never refreshes, it's not a problem. Just don't let Users see both simultaneously. :wink2:

[Kris M]

I dont have the file nor do i have FMP installed on this machine.

The reason that this whole issue came up is that i have a list view of the data and it was not consistent across the clients.. I drilled down into the problem and noticed the count issues and tried to describe them to the best of my ability.

Seems to me that if the status bar total value is correct that the unstored calc should similarly be correct but it is not.. That seemd to me to indicate that the recalc was not being triggered. I scripted a commit onto a create new record script assigned to a button and that did not produce count consistency. Because of that i think (only think here) that client instances of a found set are unique to the client. If THAT is true then how do make the client aware of a new record creation and appropriatley refresh the clients found set? If this is NOT the issue and i am still not understanding this problem then please suggest another direction of thought.

It should be simple to recreate..

Create file with one table.

Define a field called total_record_count and assign it a calculation data type. The calculation should be = Get(TotalRecordCount) and should be unstored.

Create one layout based on that TO and put a text box control on the layout that shows the value in total_record_count. Make sure the status bar is visible on the layout.

Deploy the file on FM server.

Open the file from TWO seperate client machines.

Create a new record from any one of the client instances.

Hopefully you'll notice the difference from the layout based total_record_count in the two clients and the status bar total counts. If you do not then it is an issue with how I have things set up in the file.

[Kris M]

I The file has never crashed

[LaRetta]

Hi Kris,

Get ( TotalRecordCount ) simply should work consistently no matter which client views it.

... that client instances of a found set are unique to the client.

True. If you display Get ( FoundCount ) then the number of records would be different but not so with total records. That would appear the same for all users.

...and put a text box control on the layout that shows the value in total_record_count.

I do not understand what you are saying here ... it might just be me. Are you selecting Insert > Field and placing the field on the layout or selecting the field label in status area and dragging it to layout? I don't doubt that you know how to place a field on a layout but I'm running out of ideas.

One more thing to try which would be safe ... Perform file - Save a Copy As (compacted). Otherwise, all that is left is corruption in my mind. It can't even be an indexing problem because unstored calcs don't index. Sorry, maybe others have ideas. IT SHOULD WORK FINE!

LaRetta :wink2:

[Lee Smith]

Why is this question in the General Topics?

[LaRetta]

Because I'm a worthless moderator who obviously isn't doing their job? :wink2:

[Kris M]

If this is not the appropriate place for this thread where should i have started it? Their did not seem to be any logical place to put it other than here.

[LaRetta]

This is not a problem, Kris. That's what we moderators do ... move them when appropriate. I was just so focused on trying to figure out your problem that moving it slipped my mind.

You did nothing wrong here. :wink2:

[Fenton]

I moved it to Calculations; though it really a network issue, but it doesn't really fit in either Server or Peer to Peer forums (which are kind of the same, kind of different). Oh well.

I think there are 2 separate issues here. One is when/how to refresh a Get ( TotalRecordCount ) calculation across a network. The other is what happens with client machines' found sets when a new record is created on another client.

The 1st issue is more of a screen refresh issue. A simple Refresh Window [], or anything which forces the screen to refresh takes care of it. Yes, it would be nice if it wasn't required; but it is. And it will not happen until after the client who created the record commits it.

The 2nd issue is more problematic. A new record created by a client will go into the omitted records of any other client who has a found set* (does not apply if other client is showing all records). This is logical; putting a new record into other clients' found sets would be disastrous, as they could be doing anything.

If it is important that everyone explicitly see that there is a new record immediatedly, I think that would require an "events" plug-in, to show them a message. (On a Mac an AppleScript "idle" applet could also do this.)

*This is why

Show All Records

Omit Record

Show Omitted Only

is not 100% reliable in a multi-user high-volume environment.

But setting a global, then using a self-relationship is.

[Søren Dyhr]

If it is important that everyone explicitly see that there is a new record immediatedly

I had no way to test it here, but my take at it, was to make a aggregate function over a cartesian, in my book are they more eager to freshen to the beat of a lighter drum, than the entire set of what used to be the status functions.

--sd

[Fenton]

I just tried the Cartesian count. Didn't seem to be any different.

[Søren Dyhr]

Thanks for testing Fenton.

Perhaps it could help if we knew why these numbers are important, to be honest havn't I heard of this desire before?? I could very well be that something more filemaker'ish dealt with this issue...

--sd

[Kris M]

Sounds like you need my input here...

The whole reason for this thread is because i have a list view based on a TO and they are not consistent across multiple clients when one client creates a new record the other client does not see it and i can not seem to detect when the new record is created and refresh the view for all clients.

To continue with my original description..

File 1 is open to the same list view layout on two clients. Both clients see 8(whatever) records. Client B creates and commits a new record and shows 9 records in list view. Client A still shows 8 records and the only visual cue on client A that a new record is avaialble but not shown is the status bar total count shows 9.

[Søren Dyhr]

But where is the problem in that, why do the users need this info?

Issuing a Show All Records usually make the newly created visible as well.

Fenton says what it's about:

A new record created by a client will go into the omitted records of any other client who has a found set* (does not apply if other client is showing all records). This is logical; putting a new record into other clients' found sets would be disastrous, as they could be doing anything.

We need to know why the other clients contributions, are that important. The explanation so far from you, is a more or less a carbon copy of the initial problem.

If this is a kind if Wiki, could you perhaps consider to use one single copy of filemaker, and then serve it via VNC to whatever number of client's you would wish.

What kind of metaphor is it you're trying to copy here??

If you need to know what's going on in other orders, is it not the recordnumber you should be dealing with but instead something like this:

http://www.jonathanstark.com/downloads/Inventory.fp7.zip

Or something more transaction'ish:

http://www.geistinteractive.com/downloads/Transactions.zip

--sd

[LaRetta]

Kris,

I thought it was NEVER refreshing with the new record. But you are talking about the brief period before normal screen refresh. As I explained, that is normal behavior. Why are you displaying both status area and total record count? Who cares if they are different for a few seconds? :confused:

[Kris M]

Mentioning the difference in the status area count and the get total record count was diagnostic steps by me to try and find the problem on my own.

In case some higher level details would help...

This sole purpose of this file is to record receiving inspection events at a manufacturing facility. The list view is the queue of inspection lots waiting for inspection. It is really important to have the queue current no matter which client has the list view open.

it does not seem to be a transitory problem because the onyl thing i can do to force the client to get the right records is to create a new record.

Am I crazy here or did I fail to describe the problem correctly?

Edited September 3, 2007 by Guest

[Søren Dyhr]

It is really important to have the queue current no matter which client has the list view open

Maybe the listview is where it bothers, what if you switch the layout into a selfjoin contant or cathesian portal then, all tasks creation and modifications is then fully scripted with a commit step as well. If all data is entered or modifed in global fields in a scratchpad'ish manner will everyone be able to see all records which have been committed.

Perhaps isn't the global enough to prevent record locking, but then could an extra relation a primary calc'fieldkey with Get(CurrentUser... be where things are ushered for editing and from where data is pushed back again.

--sd

[Vaughan]

Kris M wrote "... the onyl thing i can do to force the client to get the right records is to create a new record."

Issuing a "Refresh WIndow [flush cached join results]" should do it, as should switching between Find and Browse modes (a technique used in earlier versions of FMP).

If neither of these work then something is wrong. That something could be data corruption or a programming error (I've seen weird things happend when a relationships sort order contains fields that have been deleted).

[Kris M]

Thank you everyone for your discussion on this topic.

I now know why the creation of new records is a "protected" action, for lack of a better term, in FMP and does not show up immediatley on every client instance because they only show as omitted records until a force refresh is triggered. "Show all records" script step seems to the easiest step to execute that works ato refresh but I have not tested everything suggested in Vaughns reply. "Show all" seems to work so im going to use that.

Peace to all,

Kris