Question Static Class Vs Shared Temptables

We are in the process of migrating from 9.1E to 11.6. We wanted to get rid of all the hard coded values (in forms of email constants, unix commands, order types and so on), classify them and move them either into a shared temp table or a static class. Which one would you prefer?

I assume STATIC CLASS with a temp table populated with values will be same as that of using a SHARED TEMP TABLE in terms of memory; say if I have 200 users logged into the application will have 200 copies of the temp-table data.

I assume STATIC CLASS data (variables/temp-table) is for per session. right?
 

Cringer

ProgressTalk.com Moderator
Staff member
Shared anything is a big no-no. It had a time and a place, but that time and place is not the 21st Century. Some of us have to endure it for legacy reasons, don't introduce it as part of a new design.
 

Cringer

ProgressTalk.com Moderator
Staff member
Oh and a big drawback with static classes is that once they are loaded up for a session you have no control over if/when they get refreshed, so if you ship updates that involve a change to the class code then the users will need to log out and log back in again to avoid errors.
 
I would use a class. But why static?
We wanted to have it loaded once at startup (on a static temp-table). If I am using a class I will have to hit the data from DB table every time. right? We wanted the data to persist for the whole session.

I would use dependency injection instead.
I am a newbie to OO, can you please give me an example for the same? (All I would require is to load the data once and that data should persist for the whole session, should not query db table or look for config file every time)
 
@Cringer - True, I agree. But looking for the best option; as I said we don't want to hit the db table everytime or look for the config file. (It will all be a key value pair)
 
@TomBascom - Thanks, it was very useful. I would like to use this approach to get rid of global shared constants.

One quick question looking at couple of slides on your ppt w.r.t environmental variables. When we had a discussion today this point came up. Why don't we put all those global static values as environmental variables and make it available for the entire session. I know when we store some constants it may not make sense to say it's an environmental variable though it may work. Is it advisable or will it have some adverse effects?
 
Last edited:

TomBascom

Curmudgeon
It depends...

I use them in shell scripts and BAT files but mostly avoid them inside 4gl code. I might occasionally use one as a "quick and dirty"way to pass something into the 4gl but I usually end up regretting it.

ENV variables are mostly frowned on in Windows environments. In any OS they are a PITA to manage -- different shells and different ways of executing things can play havoc with their values (cron, sudo, su ...) making it hard to be sure that they are properly set.

Something that works in today's world may stop working when some seemingly innocuous dev ops change gets made.
 

ForEachInvoiceDelete

Active Member
We have a persistent procedure running on the appserver that contains a temp-table of what used to be our shared variables. We then just call dynamic functions to return data out into the application.

Just as bad but hey, makes it more readable.
 
Top