go to post Alexander Koblov · Jun 2 For already running backup or restore you can check "7) Monitor progress of backup or restore" menu in do ^BACKUP routine
go to post Alexander Koblov · May 12 This is a standard Windows error with the code 64: C:\>net helpmsg 64 The specified network name is no longer available. Some Caché code called some OS system function that returned this error and for some reason it was logged. To investigate this further -- check what process logged the error message. Find in the Caché Audit a Login event with the corresponding process. Perhaps it might give you some hint Generally, messages with severity 0 are informational, 1 -- warnings, 2 -- error, 3 -- critical
go to post Alexander Koblov · May 12 No. If you have Windows NT authentication enabled to connect to SQL Server then SQL Server ODBC driver uses OS user that executes irisdb.exe process. That's the same use as configured to run service IRIS. If you'd like to use different user for authentication , then choose SQL Server authentication and specify that user and its password in SQL Gateway connection settings
go to post Alexander Koblov · Apr 4 Try to output %oblasterror: zw %objlasterror Based on "%Admin_Secure:USE" it seems like user who runs the CSP page lack USE privilege on %Admin_Secure resource
go to post Alexander Koblov · Mar 22 The best option -- create XSD from the XML or get XSD from the XML provider, import the XSD in IRIS, that will generate set of classes to import XML to Other way -- manually create classes for each different xsi:type
go to post Alexander Koblov · Mar 19 Check carefully. Note -- in ^%ISCLOG (with percent) you enable the log. Then you read ^ISCLOG (without percent) in %SYS namespace. When I repeated steps that I suggested to you, I saw the following error in ^ISCLOG /* ERROR #5002: ObjectScript error: <PROTECT>^%CSP.Login.1 ^|^^c:\intersystems\iris2023x1\mgr\|dc.CustomLogin.1 */ Then I enabled auditing of Protect events, reproduced the eror and got more details: Description: Attempt to access a protected resource Timestamp: 2023-03-19 16:01:38.000 Username: CSPSystem UTCTimestamp: 2023-03-19 15:01:38.000 Pid: 10896 Event Source: %System JobId/JobNum: 131089/17 Event Type: %Security Session ID: eK95W6SMCS Event: Protect IPAddress: 127.0.0.1 System ID: DEP5570AKOBLOV:IRIS2023X1 Executable: CSPa24.dll Namespace: %SYS Index: 196 Roles: User Info: O/S User: CSP Gateway Routine: ^%CSP.Login.1 |"^^c:\intersystems\iris2023x1\mgr\irislib\"| Authentication: Password Event Data: <PROTECT>^%CSP.Login.1 *^|^^c:\intersystems\iris2023x1\mgr\|dc.CustomLogin.1 Indeed, user CSPSystem does not have READ permission on irissys database, where custom login class is located. Rather I should have created a new role that has only READ permission on %DB_IRISSYS resource, not RW. I added role %DB_IRISSYS to user CSPSystem, closed connections from Apache to IRIS, so that the role is added on new connection, then login page began to work
go to post Alexander Koblov · Mar 18 Documentation has an important note about this parameter: This parameter has been retained for compatibility, but should not be used when building new applications. https://docs.intersystems.com/iris20223/csp/docbook/Doc.View.cls?KEY=RAC...
go to post Alexander Koblov · Mar 18 Yuri, enable ISCLOG, reproduce the error, disable ISCLOG and then check if it has any errors, e.g. errors. %SYS>kill ^%ISCLOG, ^ISCLOG %SYS>set ^%ISCLOG = 3 //reproduce the error %SYS>set ^%ISCLOG = 0 %SYS>zw ^ISCLOG Afaik, with custom login pages user CSPSystem needs to have READ permissions on a database where custom login page class is located
go to post Alexander Koblov · Feb 16 In HealthShare section you see Extended Maintenance kits In Continuous Delivery section you'll find Health Connect 2022.3, 2022.2
go to post Alexander Koblov · Feb 2 404 is also returned when there are some permissions issues. Try to give %All to the user that you calling this API with and see if it helps. If yes -- then this is permissions issue. Or enable Audit and auditing for Protect event and see if it is logged in Audit when the problem happens Other idea -- enable ISCLOG, reproduce the problem, disable ISCLOG and see if there are any errors there. ISCLOG is very verbose, so just do one HTTP request with ISCLOG enabled enable: %SYS>kill ^ISCLOG,^%ISCLOG %SYS>set ^%ISCLOG = 3 disable: %SYS>set ^%ISCLOG = 0 analyze: %SYS>zw ^ISCLOG (yes, without %)