Global Variables


Is there a way to define a set of variables in one central place for usage in several scripts?



I managed to get this to work by making a script under "Macros and scripts" containing functions and giving the script an "Include name". Then I wrote #include "Include_Script_Name" in the trigger script and called a function from the included script, which e.g. returns a predefined string when called. This solves the issue described above.

Not sure if this is the best way to do it though. Any corrections are welcome.

RE: Global Variables

Yes, that is the correct way to go about it. :-)


Von: Tony Yates 25. Dez 2020

RE: Global Variables

OK, thanks for your reply :)

Von: Chris-Anton Eriksen 25. Dez 2020

RE: Global Variables - Dynamically updatable


The "include script"-method works for global static variables, for global dynamic variables that requires the support of being dynamically updated, other methods are needed.

The technical possibilities then are:

  1. Extra Tables
    1. Using custom extra tables, which can be created via the GUI in Service
  2. UserPreferences-table
    1. Save variables as records in the UserPreferences-table in the database
  3. ForeignKey-table
    1. Save variables as records in the ForeignKey-table


Note that method 2 and 3 uses standard tables already existing in the SuperOffice database which might be used for native features in SuperOffice as well. So it's important to understand how custom data could and should be stored in these tables without potentially affecting any native functionality.



I got some extra information about the ForeignKey-table from Tony a while ago when I got to know about it and wanted to know some more details. Tony, I hope you don't mind me sharing the information you gave me. :)

The foreignkey tables (ForeignApp, ForeignDevice, ForeignKey) were created way back in the days of Palm devices and PocketPC, and were intended to be used for synchonization and data storage. Well, smart phones came along and rendered those plans obsolete.

Over the course of time, SuperOffice has used these tables for general purpose storage. The biggest internal consumer of these tables is Inbox, syncing mail items.

Partners also use this for various storage means as well. Some are still using it, some are not.

I think I said it clear in the article, that these tables can be conceptually viewed as a multi-dimensional property bag, or multi-dimensional array.

Use ForeignKey tables when:

  • You need storage that doesn't require a user-interface
  • You don't want to offload data in an external database
  • You need a simple key-value pair storage, or...
  • You have structured information that conforms to the multi-dimensional mindset
  • All values can be represented as strings (intrinsic strings or base64)

When not to use ForeignKey tables:

  • You need a storage medium with massive amounts of storage space
  • You need a user-interface, i.e. Preferences, Custom Fields (extra fields, udefs), extra tables




I'm afraid that I don't have any good links for how the UserPreferences-table could or should be used for custom data storage.

Maybe Tony have any suggestions or tips?


Best Practices

Tony: Are there any best practices, pros and cons or potential risks using the one or the other method? Are there any specific method that are preferred/recommended or maybe adviced against?




Von: Marcus Svenningsson 27. Dez 2020

RE: Global Variables

Hi, great info, thanks alot!

Von: Chris-Anton Eriksen 27. Dez 2020