go to post Stefan Schick · Nov 10, 2022 Thanks Benjamin for the detailed explanation and the article! Now I get it: the class is mapped to a read-only database not the data and tune table tries to update the class definition. I will try using the workaround suggested by Julius.
go to post Stefan Schick · Nov 9, 2022 Hi Julius, thanks for your answer! I looked it up and the database MESSAGEBANK is already mounted R/W (what imho totally makes sense). I really don't understand where the problem lies. Regards Stefan
go to post Stefan Schick · Jul 28, 2022 Hello Alexey, thanks for pointing back to the manual! After re-reading this section I found the crucial sentence: ^JRNRESTO restores only to databases whose journal state is Yes at the time of the journal restore. So, if journaling at database level is set to "no", no journal restore will be performed! And as you said: ^JRNRESTO itself provides an option to disable journaling - at the far end of the configuration process. This might be the answer(s) to my initial question.
go to post Stefan Schick · Jul 21, 2022 Hello Alexey, Which manual does it say? I'm referring to this section of the manual: Restore Journal Files It seems that you should not bother on the subject at all: during the database restore it can't be involved in any users' activity, so there would not exist any journal record on its change. OK: to be safe there should be no activity (all productions stopped) on the entire instance during the restore process, even if only one database is affected. Regards Stefan
go to post Stefan Schick · Jul 20, 2022 Hi Alexander, thank you for the information! The ^DATABASE -> Edit seems to be the nearest solution. For a production issue I would reach out to the WRC. For sure!
go to post Stefan Schick · Mar 29, 2022 Hi Scott, when you send a message in synchronous mode (= wait for the response) to a routing engine, either by not specifing Asynchronous In the call element of a graphic business process: or programmatically: Set tSc = ..SendRequestSync(tTarget, tMsg) There are several possibilities how/what the routing engine can respond (see help for Response From): * means: return the first response the router has received to the sender If you leave this field empty a "NULL" message will be returned. Hope this will clarify it a bit. Regards Stefan
go to post Stefan Schick · Mar 25, 2022 I think I found the answer to question 1: use the .DeleteProps() method of the search table class and recompile the class
go to post Stefan Schick · Mar 25, 2022 Hi Scott, we had a similar problem with orphaned response messages. They were shown in the visual message trace as type "NULL" instead of request or respose and the MessageBodyClassName in Ens.MessageHeader was empty. We found two reasons for that: 1. business processes or operations where the pResponse parameter of the OnMessage() method was never used, e.g. Method OnMessage(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status The fix was to add a line of code to instanciate the object: Set pResponse = ##class(Ens.Response).%New() 2. Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty. The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned RegardsStefan
go to post Stefan Schick · Mar 25, 2022 Hi Scott, 1. I would stay away from Modifying the current EnsLib.HL7.SearchTable if at all necessary. Modifying the source code could lead to consequences down the road, especially when you upgrade it might get overwritten. Thanks for your answer! First: we did not modify EnsLib.HL7.SearchTable directly, our searchtable class is a subclass of this class. But defining a new searchtable as you suggest seems to make sense. On the other hand all config items using the "old" searchtable must be modified. Regards Stefan
