Background Variable Table

[MultiTech]

There are many times when I would love the ability to store a temporary variable somewhere for use during a specific process - like running a report, filtering data using an in-app filtering system, changing a ref connection for a group of records from one parent to another (migrating records), etc.

Currently their are two methods to accomplish something like this:

1. UserSettings
2. Create a table/use a column

Method #1

The problem with the first is that any changes to UserSettings requires a re-sync of the app - so for any process that needs to be speedy, this is a no-go.

Method #2

The problem with the second is that you now have an abundance of sync-calls being made to the server: one to set the variable, one to clear it, and possibly another for each alteration.

All of these syncs don’t need to be saved, don’t need to be pushed to the cloud - they’re only for use inside the app that’s using them - in fact everything will be reset to blank once the process is complete.

---

What I really need is another table that’s similar to the UserSettings - in the way that it’s a table that lives on the device with no corresponding cloud equivalent - but that doesn’t require a re-sync whenever changes are made to it, and one that we can update using Actions.

As always, thanks for considering!

[Fabian_Weller]

@MultiTech_Visions Thank you for that post Matt. That’s exactly what I also need.

[1minManager]

I agree with @MultiTech_Visions on this one. I think it would actually result in a big saving of backend time. Also in somecases we wouldn’t need to create virtual columns at all

[WillowMobileSys]

I love this idea too!

[WillowMobileSys]

I was reviewing and revising my voted items again and realized that this post is similar to the one below. Can we somehow combine these two? It would springboard it up the list!

Provide an APPSETTINGS[] list similar to USERSETTINGS[] Feature Requests

I would like to request to add a list of settings that are user updated but apply to the application across the board to all users. This would be similar to USERSETTINGS. In fact, I would recommend changing the “User Settings” tab in the editor to simply “Settings” and then have a “_PER USER SETTINGS” list of values and then a “_PER APP SETTINGS” list of values. I do understand that the same thing can be achieved by adding a sheet with these values. But the difference is how we reference the…

[Steve]

I’m not aware of a way to merge posts, and I suspect a lot of the votes between the two posts are overlaps, so combining them may not be quite the win you’d hope. I could close one of the topics, but I have no way to migrate the votes.

[MultiTech]

Steve:

I could close one of the topics

Does that release the votes?

[Steve]

I really don’t know. I’m assuming it does.

[Fabian_Weller]

No it doesn’t! You first have do “devote”.

[pravse]

Yes, the APPSETTINGS requests would cover this one too. Let’s just track that and treat this as a duplicate.

[stuggijo]

Me two thank you

[HBT]

This is a must. +1=17

[MultiTech]

praveen:

Yes, the APPSETTINGS requests would cover this one too. Let’s just track that and treat this as a duplicate.

If AppSettings() is intended to be App-wide - meaning whatever variables I set there EVERY user will see - then this wouldn’t be a duplicate.

I’m looking (still looking ) for a way to reduce the back-and-forth necessary with “user-specific global variables.”

• Currently the only method that works for active dashboards and such is to have columns somewhere (in the user table usually)
  • but this is all that back and forth I’m talking about.

MY app needs to have that information, but if you’re using it all that is superfluous; just like your dashboard setting changes are pointless to me.

---

(I made a post awhile ago about this, but couldn’t find it - read: didn’t try very hard. haha)

Instead of a whole table - it would be easier if we could just mark columns to not upload whatever changes they have to the server and store them locally only.

• To the database it would look like a show column… empty; but on the device it would hold their value in that field.
  

EDIT: found the post:

Device-Only Columns (Moon shot request) Feature Requests

Often I find that I need to build a place to store a temporary variable (something that a user can select, and when they do it triggers or brings about special functionality [like sorting, or filtering for the specific selection the user made, etc.]). The problem here is that as people interact with the system, they accumulate many (sometimes dozens) of updates that have to be uploaded to the cloud. [image] In the gif above, each time I change the…

[WillowMobileSys]

MultiTech_Visions:

If AppSettings() is intended to be App-wide - meaning whatever variables I set there EVERY user will see - then this wouldn’t be a duplicate.

What if the AppSettings table idea could be modified to have a Global and Local flavor of settings values?

Global means for all users of the app. Value included in Sync.
Local meaning just for the device. Value NOT included in Sync.

[MultiTech]

A nice combination of both!