Globals and IWP

[andrewf]

I have a db that has a global field in it. They only way I can get the field to be propagated from FMP (the non-iwp application) to IWP is by closing and opening FMP. I've tried flushing cache, moving from one record to another...for some reason it just doesn't like global fields.

This seem like a rather big bug.

[Søren Dyhr]

They only way I can get the field to be propagated from FMP

Globals are restricted to each loginID, so tagging records for public views does not work neither in IWP nor in native mode. It's a common flaw in the reasoning... like this:

http://www.fmforums.com/forum/showtopic.php?tid/180060/post/220779/hl//

Instead use something in the vicinity of:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=550&mode=thread&order=0&thold=0

...and do the trimmings on primary side instead. Another approach is this:

http://www.newcenturydata.com/downloads/filter.zip

--sd

[andrewf]

Hmmm. That would make sense, but with either native or IWP when I even try to log in with the SAME userid, the global is not propagated.

[Søren Dyhr]

That depends on what you mean by propagated, a calc'field containing a global field will only have a value on the visible record pulled by the layout event, all other records shows nil - the reason is that every calc' using a global value is bound to be unstored.

I'm afraid that using global is wrong here, propagation should be scripted via loops in stored fields in each record requirering the values presence. Even so is it a slightly iffy, since each user sees a snappy of a records data, while you behind the screens alters stuff on your own behalf.

Approached more structually should a value not occure too many times, before breaking it out in a related table ...if all records needs to approach values use the carthesian product relation type.

--sd

[andrewf]

Okay, so I may be using the global wrong but it's a pretty straight forward field. I've got a db that has a single field that is shared amongst all the records. It's a text only field in the body of the record. The idea is that it can be updated from ANY record and show up the same on all records. Seems like IWP and native just don't play well together.

I'm sure there is some other way to do this, but this is how I've always done it in the past.

[Søren Dyhr]

Have you tried to make a cartesian relation with an ordinary field, you have however to take the modality in the IWP session into the account, you would need to use CWP and your own java script brew to gain a spreadsheetish responsivenes, it's the same with lookups they need to get freshened as well by commiting/submitting the record.

--sd

[andrewf]

Okay, you lost me there. Unfortunately, you're talking way over my head. I truly thought this was a simple implementation. Having a record that has a single field that is shared among all records.

For example:

- A db that has 10 fields

- 1 field is a global text field - field(g)

- entering data from any record within the global text field should show up in all of the records in field(g)

- when viewing the global field from native FMP the data is the same

- when viewing the global field from IWP the data is latent based on what in the field last time FMP was opened (native).

It's just global text field, no calculations etc. As stated in the previous message, I've tried doing commits to make it work.

[Søren Dyhr]

Well my english isn't sufficient here, when you both are logged in natively and via IWP are you not just you, but your doubleganger who is the proprietor of yet a new global field which needs to get initiated by a script during login... or if the data is common to all users such as a logo could a cathesian product relation be used ( see image above)

Somwhere in between could Get(CurrenUserName) be used as primary key for a straight forward equijoin relation. This way have each user his own set of data or attributes.

--sd

[T-Square]

Andrew--

I think what's not getting through here is the fact that global fields are set for a given session. So even if you log in with the same userID at different machines, each session has its own set of globals. This is documented, and is just how globals work in a networked environment.

What I think Søren is trying to convey (correct me if I'm wrong!) is that you could use a separate 1-record table with a regular field to hold theData, which will carry across sessions. He is recommending that you use a "cartesian" relationship to join *any* record in Untitled with *any* record in TheCommonData (to use his example). Since there is only *one* record in TheCommonData, the result would be what you seek--every record and every session would show the value stored in TheData.

HTH,

David

[andrewf]

I'll have to dissect that (and learn more about implementing it) but would that approach work for modifying this field as well from either IWP and Native?

[Søren Dyhr]

Thank you David, it was indeed what didn't come thru, although i tried:

So even if you log in with the same userID at different machines, each session has its own set of globals.

But I would also stress here, that people comming from other RDBS tools expresses a puzzeled notion to the actual use of both repeaters and global fields, since the relational tools more adequatly adresses these issues. They are illitimate children or bastards in the toolbox to honest.

--sd