Global refresh issues

[TRF]

Don't know if you've discussed this - but I'm part of a group of developers building a rather large solution using the separation model. We frequently use global fields to affect many dynamic interface issues. When global fields are pulled over through a non-native TOC rather than being native to the file you're working in - refresh becomes a serious issue. You can kick it and spank it - but ya can't get it to fresh. Similarly - when trying to use dynamic value lists - the content of the initial field does not refresh quickly enough if its from a non-native TOC. bleh!

[mscholtz]

I think I just ran into this. I've got a two-file app I'm working on (1 ea. for data & interface).

I've got one particularly complex arrangement where a compound calculated key is built in a table in the data file, based on a dynamic value list in that file. Then this key is used in a relationship in the interface file. (It sounds convoluted, I know, but it works - almost.)

But refresh doesn't work, because the key field isn't updating. I found that in order to get it to refresh I've got to actually go to the data file, to a layout containing a portal based on the relationship the key field is based on, run a Refresh (flush cached) there, then go back to the interface file and run another Reflesh (flush) there. THat does it.

Of course, that's no answer because I don't want to display the data file on screen. Would be nice if these two functions (refreshing relationships and refreshing layouts) weren't joined at the hip in FM7.

I'm guessing this is just one of those unadvertised pitfalls of the "separation model", but if anyone's got any suggestions in the short term, I'm all ears.

[Oldsneekers]

How about ending a script with: setfield (RMF: RMF) where RMF is the relationship match field. This enters the value in the match field for a relationship with its own value. I have some dynamic portals and the portal sort order would't update to the new values until I did the above. Even if a relationship used multiple matchfields, using the setfield above with any one of the MF's did the trick.

Good luck.

[-Queue-]

Refresh Window [Flush cached join results] should also work.

[Oldsneekers]

I just started the separation transision and ran into the same problem with global refresh issues. If there is a script handy then the refresh window step helps but, if not, this becomes a problem (more cosmeticly than functionally). After some thought I decided to cheat and put the globals in question on the user interface file. This works perfectly now. I decided to sacrafice pure separation in favor of workabilty. (I never realy understood why the calcs and globals "have to reside" in the BR file rather than in the UI file anyway)

Good luck (to us all).

[cmury]

I've also run into this issue. http://www.fmforums.com/threads/showflat.php?Cat=0&Number=150774&an=0&page=0#150774

Has anyone attempted to generate the global and calaulated key in the UI file and form the portal relationship on that basis? I'm thinking that all will then be native to the UI file. But I assume this process would require a 'dummy' table of vaules in the UI file.

Oldsneekers - this sounds similar to your [non-script] solution. But did you require this table in the UI?

I'm keen to hear if anyone has experience with this or any other work around.

C

[Oldsneekers]

I have been away for a while. But to answer your question, yes. I have a TO in the GUI file where certain of my globals reside. The layout is formatted to the GUI global T.O. I do not, however, put globals that are used in calculation fields by other T.O.'s in this GUI table. For example, corresponding the ClientDATA table, I have a ClientBR table in the BR file. this BR table holds all globals that are used by calcuation fields in this table. My BR tables have no data (other than the recordID that relates it to the data table), just calcuations and globals.

Good Luck. Once you get the hand of it, I thing the separation model is much easier to navigate since all layout are in one file, navigation is seemless. I use multiple files only if I plan to have certain upgrades of data. This way I don't have to import, simply replace the newf ile for the older file inside the folder.

I'm a convert.