Question on Global Variables

[K1200]

I've been trying to use a Global Variable to specify one of my search criteria in scripts, as demonstrated by the following examples.

THIS WORKS (returns only Basin records)

Enter Find Mode []

Set Field [Table::PlantID; "Basin"]

Perform Find []

AND THIS DOESN'T (no error, but returns all records)

Enter Find Mode []

Set Variable [$$ID; Value:"Basin"]

Set Field [Table::PlantID; $$ID]

Perform Find []

Can someone tell me why it doesn't work -- or suggest an alternative?

What I'm trying to do is load $$ID with the contents of a Logon::PlantID field (located in an unrelated table) in a central script and then use it throughout my report scripts.

Any help will be appreciated.

[Fitch]

Try setting the variable before you enter Find mode.

[K1200]

Fitch, Thanks!

That was it!

But how should I have known that? I can't find any mention of use restrictions in FMP's Help pages, or in the couple of books I have.

Are you aware of any reference?

[comment]

It seems that your example is inaccurate, and that you are trying to set a variable to a FIELD VALUE - but only global fields have values in Find mode.

Edited April 27, 2006 by Guest

[K1200]

At this point, I've implemented the following and it's producing the correct results on each report:

Set Variable [$$ID; Value:Logon::PlantID]

Enter Find Mode []

Set Field [Table::PlantID; $$ID]

Perform Find []

"Logon" is an unrelated table that I use to hold high-level parameters. Is this a non-standard usage that just happens to work?

[Fitch]

In your original example, you set the variable to a text string. This will work while in Find mode.

But in you most recent post, you show what you're really doing: trying to set a variable to a field's data while in Find mode.

As comment noted, that won't work unless the field in question is a global. This is expected behavior, because in Find mode you're not on any record, and relationships are not valid.

Also, regarding your latest post: you can't access data from unrelated tables unless it's from a global field. "Logon::PlantID" either is in fact related, or it's a global, or it won't work.

[K1200]

To clarify things a bit: the Logon table is defined to have an "X" relationship with the application's main table, but with no individual fields defined as part of that relationship. My understanding is that that effectively makes parameters in Logon "global", which corresponds with your explanation. This is certainly an area of usage that would benefit from additional documentation in FMP.

Thanks for your help.

[CobaltSky]

To clarify things a bit: the Logon table is defined to have an "X" relationship with the application's main table, but with no individual fields defined as part of that relationship.

Hello K1200,

Even a cartesian product relationship ("X") requires that individual fields be defined as key fields for both sides of the relationship.

My understanding is that that effectively makes parameters in Logon "global", which corresponds with your explanation.

That's not the case, I'm afraid. Global fields exhibit a number of properties which are not applicable to standard data fields, even those which are related via a cartesian product relationship. For instance, the values in standard data fields cannot be accessed in Find mode, whereas global field values can, standard fields can have numerous instances** (ie one per record in the table in which they reside) whereas global fields can have only one and their contents are the same for all users (whereas global field values are specific to the user). There are other differences - so as you can see, it's not safe to assume they are "effectively global".

** or set of instances in the case of repeating fields.

[comment]

Even a cartesian product relationship ("X") requires that individual fields be defined as key fields

Well, yes and no. That is, you must use a field on each side in order to CREATE the relationship. But after that is done, you can delete the fields, and the relationship will continue functioning.

[CobaltSky]

Well, yes and no. That is, you must use a field on each side in order to CREATE the relationship. But after that is done, you can delete the fields, and the relationship will continue functioning.

Heh. True enough, Michael!

Not something I'd generally recommend, however, because to the best of my knowledge that's an 'undocumented feature' or maybe even an 'unintended quirk' in current versions of FIleMaker. YMMV

...[cue Twilight Zone theme now]... :Whistle:

[K1200]

My statement of the Logon table "X" relationship was a bit over-simplified. Yes, a "technical" relationship exists for FMP's internal needs, but from a practical standpoint, it's an overhead record, unrelated to any other tables in my database. I formulated my solution from a post a few weeks ago in which "Raz" offered the following:

"Since FM7, the need for globals has been vastly reduced, if not eliminated. .... Try creating a 'preferences' table that contains all of your overhead fields as non globals. Then create an all to all (x) relationship into your graph (I use the uniqueID fields as the key fields). You will need one and only one record in this table. "

It has worked great for me so far, but I'm always trying to expand my understanding of FMP and all of your suggestions/comments are appreciated.

[CobaltSky]

...I formulated my solution from a post a few weeks ago in which "Raz" offered the following:

"Since FM7, the need for globals has been vastly reduced, if not eliminated. ...

Well, I don't believe I saw the post you mention (there is a user named RAZ registered on this forum and s/he has made only one post, but it does not refer to globals).

Notwithstanding that, I am not pursuaded that that is good advice. Globals still have a number of worthwhile uses, even in FileMaker 8. :shocked:

[K1200]

Sorry, I don't know how to post a direct link, but the topic was:

"Need advice on globals" (Topic#174779)

[Lee Smith]

You copy the URL, and then do [color:red]REPLY and then click on the Globe (a button in the cluster that has B I U etc.

This will give you a dialog box where you paste in the URL, and then you get a second box where you can type something like "[color:red]Click Here" or Click here to go to the correct link

BTW, your referenced Subject was right, but the number was off.

Lee

[CobaltSky]

Okay, I found it. But I'm afraid there is not much substance to the 'argument' presented there.

I recall a thread from a year or so ago - which it seems has since gone missing - to which I posted some comments about the continuing uses of global fields. As I recall they were pretty much as follows:

1. Global fields can be accessed from any table on the graph without a relationship - and without them, the task to ensure that a single value can be accessed from any layout throughout a solution is daunting - and it can turn the relationships graph into an unintelligible mess.

2. Global field values are persistent in find mode. There are any number of reasons why this is useful - such as ensuring that the company logo does not disappear from view.

3. Global field values do not depend on a record being present in the table where they reside - nor does their accessibility from other tables depend on any records being present in those other tables - something which is essential for constinuity of reference values during an update process etc.

4. Global field values are specific to the client in a hosted solution. Whilst there are other ways to ensure that each user will see his/her own values whilst a solution is being hosted, there is none that requires so little overhead, nor which is so reliable in its operation in this respect.

5. When defined as calcs which reference standard data fields, Global fields independently/automatically reference the record on which the referenced value/s were most recently edited on the current client workstation. This is a powerful capability with dynamic control and audit capabilities.

I think it is important to recognise the various properties of different field types and to play to their strengths. I think it will be a while yet before we run out of uses for global fields. :wink2:

[K1200]

Ray, thanks for the clarifications.

In my application a separate table of overhead parameters (i.e., Logon) makes sense -- common sense -- even if it is a little simplistic in the relational sense.

And I remember reading that contents of Global fields can sometimes be lost -- like when cloning a file -- so they can't be used for things like application-level parameters, which some of my Logon fields are (application configuration and identification parameters).

So maybe the best approach -- for me anyway -- is to keep the separate table, but designate those individual fields that need to be used in Find mode as Global. Is this a reasonable approach? (Or is reasonableness in the eye of the beholder?)

I do appreciate the discussion and advice.

[CobaltSky]

By all means, you should use whatever works best. But it is always better to make such decisions with the facts in hand.

In my application a separate table of overhead parameters (i.e., Logon) makes sense -- common sense -- even if it is a little simplistic in the relational sense.

Simple is fine, provided it does what you want. In this case, that won't include being able to access values in find mode, for instance, or having users editing the values independently etc etc. But so long as you're comfortable with that, the cartesian join approach should be workable.

And I remember reading that contents of Global fields can sometimes be lost -- like when cloning a file -- so they can't be used for things like application-level parameters, which some of my Logon fields are (application configuration and identification parameters).

The contents of *all* fields, not just globals, are lost when a file is cloned. So you may need to think that one through further. Ie if that is a 'disadvantage' of globals, then it's a disadvantage of your one-record table approach equally.

So maybe the best approach -- for me anyway -- is to keep the separate table, but designate those individual fields that need to be used in Find mode as Global. Is this a reasonable approach? (Or is reasonableness in the eye of the beholder?)

Yes, a 'mix and match' approach can work well.

One caveat is that you'll need to be careful to keep track of which fields are global and which are not, so as to be mindful of how they will behave. Naming conventions may help you with this. :wink2:

[Tyrant]

in my current db development i am doing the following (fm8 multi-tables)

one table for Globals (variables)

w/fields such as Temp1-40 for placeholders

other tables for Assets (inventory)

w/fields such as AssetID, Manufacturer, Name, Model

functions as such.... for multiple asset search

button from main menu to layout with global temp's and create new record

user scans asset barcodes then clicks "search" button

"search" script goes to list view, uses set field for temp1 = assetid then create new request, temp2 = assetid and so on

freeze window, perform find, goto original layout, delete record (global temp), goto list view

basically creates a global record to prevent multiuser record locking, conducts the search, deletes temp record, display results.

yeah its not the best way but it works for me... and may be helpful to others