Global Fields would be very useful

[Octavio_Lopez_S]

Hello,

A “Global Field” is one that the whole table uses as if it was present in every record.
Like when you define a cell with a “Name” in Excel.
The benefit is that you change it in one place and it affects every record.
Imagine the exchange rate (Dollars-Euros) affecting the price of something… or the weather forecast affecting something else.
A workaround: I can create a base with the Global Field and a Formula that equals that field in a different table. The problem is you need to link to the Global Field and then bring the info with a lookup…
This may require a separate table for each Global Field which is far from ideal…

Thanks.

[jorgept]

Your workaround is almost perfect, but a little too convoluted.

What about having a formula that equals a fixed number instead than doing a lookup to another table?

[Octavio_Lopez_S]

Hi jorgept,

I don’t like that because the fixed number is hidden in a formula. The formula can be complex, you know…
It is better when the Global Field shows and is a “parameter” that is clearly meant to be updated if necessary.

THX

[Jeremy_Walker]

Would love to see this as well.

[W_Vann_Hall]

I sometimes make use of two types of pseudo-globals/pseudo-constants.

One is along the lines of what @Octavio_Lopez_Sierra described: A formula that evaluates to a fixed value. For instance, in Wardrobe Manager, {G_displayUnits} is a formula configured as either 'IN' or 'CM'; it determines, unsurprisingly, whether certain measurements are displayed in inches or centimeters. I called this a ‘pseudo-global’ or ‘p-global.’ Such values are more appropriate to control presentation or UI, as once they are changed, they affect both existing and new data, To make use of them outside of the table in which they are defined, one must use a linked reference — e.g., a lookup or rollup field.

I also use what I call a pseudo-constant (p-constant). (I suspect these terms had more specific meanings when I first thought of them…) As it now stands, a p-constant is simply a text or numeric field with a default value. Typically, their scope is restricted to the containing table, but the can be referenced through a lookup or rollup, if one is careful. The big advantage of a p-constant is that changing one’s value affects only data going forward; existing data isn’t changed — assuming the implementation is correct.

As an example, look at the data entry counterpart of {G_displayUnits}: {C_entryUnits}.
{C_entryUnits} is a single-line text field whose default value is either — big surprise! — 'CM' or 'IN'. As such, a separate instance of {C_entryUnits} is stored with each new containing record created.This means the data in the record can make use of the p-constant without becoming corrupted should its value later change. As you might guess, {C_entryUnits} determines whether the measurements later displayed according to the value of {G_displayUnits} are to be entered in inches or centimeters.[1]

Imagine this scenario: A user creates a wardrobe and populates it with garments; as she’s an American, she sets both {C_entryUnits} and {G_displayUnits} to equal 'IN'. (For argument’s sake, let’s say she’s a burlesque dancer, part of the ongoing Burly Q renaissance.) A few months later, she joins with two other dancers to form a troupe; as part of their agreement, they pool costumes and related resources. One of her partners is French, and when she came to the U.S., it was in the company of a number of large, heavy trunks.

When Mlle Mademoiselle sits down at the PC to browse the collection and add to it, she slams into the English measurement system. True, most entries include not just the nominal, stated size but also record the garment’s significant dimensions (bust, waist, sleeve length, etc.), so she can tell if even a bespoke, unsized item might fit — after she multiplies the reported size by 2.54. Even worse, when it comes time to enter her own records, she finds she has to divide every carefully taken measurement by 2.54 before she can add it to the database.[2]

Instead, she changes the two pseudo-constants from 'IN' to 'CM'. {G_displayUnits} acts like a true global, so that any dimensional measurement displayed to her is in centimeters, including all those originally entered in inches. The current value of {C_entryUnits}, on the other hand, affects only those records created after the value changed: The 7½″ rise of those hiphugger cha cha pants — which Mlle Mademoiselle sees as 19 cm — remains 7½″/19 cm long internally, rather than being interpreted as 7½ centimeters. However, when she enters the waist dimension of her banana skirt as 61, the system ‘understands’ she means it’s two, not five, feet in circumference.

If the third partner should also be from this side of the pond and changes the pseudo-constants back to 'IN', the cha cha pants again will have a 7½″ rise, and she’ll see that 61 cm skirt, at 24″, will be, alas, too small.

Again, not a replacement for a true global field, but at least a way to exploit some interesting and useful functionality that’s part of the current product.[3]
. __________

1. More correctly, {C_entryUnits} determines how unhinted dimensional measurements should be interpreted; regardless of its current setting, measurements can be explicitly set as inches by appending ‘"’, ‘in’, or ‘i’, or as centimeters by appending ‘cm’ or ‘c’.
2. Not really, but for argument’s sake, let’s pretend that’s how it works.
3. Unfortunately, a bug in Airtable makes this a little less useful than it might be.

[DavidMa]

This is such a constant need and the lack of it creates so much extra work that I assumed I was missing something and was just about to post a question asking how to create a global field. Almost every Base I have has the same fields used again and again across tables, for instance a URL field named “website”. Am I missing something or do I really need to create that again and again for every single table in a base?

[W_Vann_Hall]

DavidMa:

Am I missing something or do I really need to create that again and again for every single table in a base?

Is there a reason not to use a lookup/rollup field in this instance?

[DavidMa]

Probably that I just started using it and don’t know what I am doing :grinning: ? That was the first thing I tried but it didn’t seem like what I needed. I’ll have to read the help on it again. I was expecting to find something like “use existing field”.

Thanks

[Larry_Fjeldstr1]

I totally agree that Global Fields would be very useful – maybe mandatory. In the mean time, I have come up with a way to have a pseudo-constant.

Here is the scenario: Date fields sometimes go strange because the server may be in a different time zone. Hence the TODAY() function may give a date different than where the user is. Here is what I did:

Create a field in your table, let’s say “TimeZone” (Number type) (Integer) (Default value of -7)
Hide the field.

Then in a formula field it is referenced as: DATEADD(NOW(),TimeZone,‘hour’)

This way, you don’t ever have to re-enter the timezone and can reuse this as a variable in any field in the table. I haven’t got a way figured out to do this referencing TimeZone from another table. Likely can’t do this.

The overall benefit with this method is that when new records are created, the TimeZone “variable” is always populated as a field in that record. If you have to change the TimeZone, you just change all the values of TimeZone to the new value, and change the default value to the new value.

Hope this helps at least in some small way.