In a simple configuration, one namespace uses one database.
But often, a namespace is a combination of a code database(=Routines), a data database (=Globals), and a bunch of mappings to other databases.

Looking at the names of your databases, it could well be the case that you need e.g. a namespace MYDATA1 which points for code and data to the database MYDATA1, and has Global Mappings for a list of specific globals to the database MYDATA1TEMP.

(You can see this list If you go to the portal -> explorer -> Globals, and select in the first combo 'databases' and the second 'MYDATA1TEMP', you should see a limited amount of globals that will probably hold temporary data which is stored seprately from you other live data.)


Ideally, the backup should also backup the file cache.cpf to get a list of the configuration of namespaces, databases, and mappings.

I had a similar problem where api calls could take up too much time to immediately respond.

So i immediately return as a response just a queryid (incremental number), which the user can use in a separate call to get the status, and in a separate call to get the results when the status is 'finished'.

Each call to the query api is stored in a table with the incremental queryid, the request and status='queued').
I have a job that will look at the next 'queued' request in the table that needs to be processed, set the status to 'in process', process the query, change the status in the table to 'finished' (and also store the results in the table).

So each query is processed one by one, and 'users' have to wait and use the status call to check when their query is processed. I also have a purge function that will delete processed queries after 14 days (so users can get the results within this period).

The api call that returns the next queryid will check if the background job is running to process the queue, if it is not running, it will job it. I also have put this method in the %ZSTART so it is started when Caché/Iris starts.
The background job in a loop process the queries, and will hang for a minute if there is nothing to do. (There are also ways in Caché/Iris to let the job 'sleep' and 'wake up'.)
 

If the .DAT file was copied while Ensemble was running, it could be corrupt (there could be blocks that were written in memory but not yet to disk). The only reliable way to use a .DAT file as backup is when the file was copied while Ensemble was down, or when the file was dismounted. (the .lck file should not be present in the same directory as the .DAT file)
The good thing about a backupped .DAT file is that you can mount it as a new database, and copy stuff from it while the rest is still running as is.

Hi Mark,
It is stated in the doc that %All is not enough : you have to have the exact role or be the exact username that matches row level security (in your case : the property FACILITY in each row).
Alternatively, you can disable it by setting the securitypolicy param to 0 (but then you need to recompile the classes that depend on it and rebuild the indices)
https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls?...

Hi Mark, If you can do inserts but not selects, the class might have row security enabeled.
Is there a parameter  ROWLEVELSECURITY = 1, and a method %SecurityPolicy present ? In that method, you can exclude rows based on e.g. $username and $roles. Even if your user has the %All role, you could be excluded to see a row in this security.
If you see that, you can or create the correct user/role, or set the parameter to 0 (and rebuild all indexes).
Can you send the class definition of one of the tables, so I can try the class on my server ?

Hi Tiago,

There is always a risk of getting errors after an upgrade, depending how your application uses Caché.
For example : your application could use custom data/code that is stored in the manager's database, and that database will be overwritten in the upgrade, so you will risk loosing data/code. (It is bad practice to store info there, but it is possible) 

Best is to contact the vendor/developers, and test the upgrade by copying the server to a test server and do the upgrade there.
 

Be carefull : the second parameter of $zdateh is =1 for US format (mm/dd/yyyy), =4 for European format (dd/mm/yyyy) and =8 for yyyymmdd format.
Luckily, $zdateh is smart enough to know your date is really US and not yyymmdd, but the correct answer is to use $zdateh(x,1) > $zdateh(y,1), and not 8 as second parameter :

write $zdateh("05/01/2022",1)
66230  -> the internal date for may 1st 2022
write $zdateh("05/01/2022",4)
66114  -> the internal date for 5 january 2022
write $zdateh("05/01/2022",8)
66230  -> $zdateh expects yyyymmdd, assumes this is US format (but this is wrong if European format was intended)
Set Attribute Mode	<ESC>[{attr1};...;{attrn}m
  • Sets multiple display attribute settings. The following lists standard attributes:
    0	Reset all attributes
    1	Bright
    2	Dim
    4	Underscore	
    5	Blink
    7	Reverse
    8	Hidden
    
    	Foreground Colours
    30	Black
    31	Red
    32	Green
    33	Yellow
    34	Blue
    35	Magenta
    36	Cyan
    37	White
    
    	Background Colours
    40	Black
    41	Red
    42	Green
    43	Yellow
    44	Blue
    45	Magenta
    46	Cyan
    47	White