Current RecordID in a global calc field

[genevieve charbon]

Hi,

I want to be able to put the recordid of the displayed record (in form view) in a global field automatically without script.

Doing Get(RecorID) in a global calculation returns the last record id of the whole database. I tried a self relationship based on record id in a global calc, without much success either.

I've thought of FM 8.5's get object layout, but my solution has to work on 8.

Any help ?

[Søren Dyhr]

I've heard or rather read a lot of questions in this direction, I think we need to establish what you wish to achieve by it, is it highlighting the current record in a selfjoin shown in a portal??

Investigate attached template!

--sd

Highlight.zip

[genevieve charbon]

It's not in a self join.

See the following image.

I've File A which contains products commercial text

I've File B that contains the product carscteristics

Table 1 of File B contains the different possible caracteristics

Table 2 of File B contains the values of the caracteristics.

Table 3 of file B, not depicted, contains the potential caracteristics a product of a particular categorie could have

On my layout, to display the potential caracteristics this produt could have, I first I create a multikey containing all the caracteristics of the categorie of this product.

Using that multikey, I display all the caracteristics in the green portal.

in that portal I can put the values (orange area) of the caracteristic of the product from table A.

Green table 1 of File B doesn't relate to the product A, but it's portal has to allow me to set the caracteristics of the product in the orange table 2 o of file B.

So, I need to pass the product sku to the green table, and I do it with a script that sets the global UI_current_product_erp in the green table.

I don't want to rely on a script to set that variable, I want that the simple fact of being on the layout of table B showing a particular product would update the global UI_current_product_erp in the green table.

If I could put the sku of the product currently displayed on my layout in a golbal of file A, then, with a 1=1 relationshipt I could set a calculation in the green table that would have the sku value.

[Søren Dyhr]

Well I would probably dissagree with the relational structure utilized, if I could diggest it! Without knowing what kind of method got you to the present structure are today - will I however suggest you watch this video:

http://previews.filemakermagazine.com/videos/513/DataTagging_full.mov

Or consider the approach David Kaschel multi tiered table structure using the same table for even grandchildren or grandgrand...

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

--sd

[genevieve charbon]

Your links seems interesting, especially the pdf one, I 'l read it.

BUT, I know about infinite hierarchies, and I use them for the green area.

Anyway, the topic is to have a global updated automatically without script, as if global calculation would work as they should.

[comment]

A simpler example, isolating the problem, would be more useful. As it is, I am going to hang on this sentence:

I want that the simple fact of being on the layout of table B showing a particular product would update the global UI_current_product_erp in the green table

I'm afraid that's not going to happen. Certainly not with a global field, that is by nature stored. It MIGHT be possible with an unstored calculation, relying on a variable - but I don't understand your relationships well enough to say yes or no. It seems like you are trying for a left outer join, but with 2 side-by-side portals? I don't know how that works.

Can you make a simple demo file with only the 3 or 4 tables involved?

[genevieve charbon]

I've only depicted the file to point it wasn't a self join, I don't need assistance on the file as it is very complex and works ok (the only drawback is to trigger the passing of the sku in another file with a script).

Any change to the structure won't be worth it because it would impact way too much my solution

I'd like just like to avoid the aforementioed drawaback, but I can live with it.

So don't consider the file, but just consider to this simple question :

How can I pass the sku number (a field content) of the record currently displayed by the form layout of File A I'm working to another FILE B storing it as a global on file B

[comment]

I don't need assistance on the file

No, but I do. :

The real question is not how to pass the number, but rather will it react properly to changes in File A. In most cases, I'm afraid the answer will be no. Although the calculation will work (i.e. it will show the correct result when you click into the field), Filemaker will not always refresh the screen (which is not important) and will not update the join cache of the dependant relationship (which is critical). That's why I asked about the relationships.

FWIW, you can see how to pass the data here.

[Søren Dyhr]

FWIW, you can see how to pass the data here.

Ah! Yes the lesson learned from (I couldn't remember where and what):

http://www.kevinfrank.com/download/county-highlight-in-portal.zip

...if it weren't so that several files are used here (notice the cursives in the drawn TO's), so passing of either $variables or $$variables is unfortunatly wishfull thinking.

--sd

[comment]

Unfortunately, that's true: it will not work between separate FILES.

BTW, you might want to compare the attached file to the one you linked to. Note that despite the long list of illustrious names mentioned there, most of the stated limitations are pure voodoo. So the lesson is NOT learned from there, but from here.

PublishCurrentKF.fp7.zip

[genevieve charbon]

Thanks Guys,

The separate FILE ruins every hope I guess :-(

And "comment" you are right with the updating not working very well due to the need of flushing, even with my set filed script steps. I've added a commit and now it seems better.

I don't get with the §§ variable are limited to the file scope, it should be in memory (an $$ should be allowed as keys in relationship)

[Søren Dyhr]

You are using this forum wrongly!

I don't need assistance on the file as it is very complex and works ok

How can we be sure, we only have your word for it - do you know how often we here encounter examples of use of global fields were a poor fix to a unhealthy relational structure?? Allow us to be sceptical since you very unrevealing!

If you won't let us come with you into your reasoning are you gambling with very long odds. Do you honestly think everybody utilizes the relational tools availiable the same way as you do? Only to pinpoint you to a quick remedy - Do you think, we have a vast collection of fixes, we know by heart.

I would dare say that the use of globals in the first place is wrong! But could be proved wrong if we had something to investigate!

The difference between understanding and knowledge is the difference between "learning" and "memorizing". People who have understanding can undertake useful actions because they can synthesize new knowledge

...snipped from: http://www.systems-thinking.org/dikw/dikw.htm

--sd

[genevieve charbon]

Hi Soren,

If I had the time, I'd welcome your help, and could discuss it at lentgh.

What I'm sure is that I've no time, that my solution works, and that the remedy would help save me a script but that's not a deal breaker.

So I've looked for a quick fix. If there's isn't that's no use for me cause time/amount of work issue.

For starter, if I had the time, I've pit everything in one file to use $$ variables, that alone could save me a lot of globals.

For you all to get a good laugh, here's the relationship graph of just the pink file. So you'll understand that although I should, I can't change much.