Jump to content

Globals and IWP


This topic is 6472 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

pling.jpg

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 6472 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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.