go to post John Murray · Jul 4 I think the command to export from a project only exports the project's server-side classes / routines to individual client-side files. Since your title mentions deployment I'm guessing you want all the project members exported into a single XML file. An export of multiple server-side items to a single XML can already be done using the `ObjectScript: Export Documents to XML File...` command from Palette. But currently this can't auto-select only the members of a project.
go to post John Murray · Jul 1 I don't think there are built-in features that would meet your need. I strongly recommend adopting a source control solution such a Deltanji from George James Software (my employer). The material at https://georgejames.com/Deltanji focuses on IRIS but Cache is also a fully supported platform.
go to post John Murray · Jun 30 Did you experiment with setting the default qualifiers for the namespace, or for the instance as a whole?
go to post John Murray · May 7 One way would be to add a check for the existence of a process-private global (PPG) node. Something like this: lock +^TEMP("FOO"):0 //don't wait quit:'$test quit:$get(^||CRITSECT("FOO")) set ^||CRITSECT("FOO")=1 //critical section //... kill ^||CRITSECT("FOO") lock -^TEMP("FOO")
go to post John Murray · May 1 FYI the most recent beta VSIXes of Server Manager and the ObjectScript extensions now do their best to end web sessions when they're exiting or restarting. The relevant versions are v3.10.1-beta.2 and v3.0.2-beta.9 respectively. A similar change in the Language Server extension is being prepared.
go to post John Murray · Apr 23 Current doc link is https://docs.intersystems.com/iris20251/csp/docbook/DocBook.UI.Page.cls?...
go to post John Murray · Apr 21 database2 When you add the entries to the table of global mappings they are automatically listed in priority order. The mapping algorithm begins at the top of the table and searches downward, stopping as soon as it finds a row that applies.
go to post John Murray · Apr 7 IIRC, you'd use `Go to Definition` to get to the method code. According to the Language Server README `Go to Declaration` is relevant for variables that are declared as method arguments, or listed in the PublicList of the method, or are declared with #Dim
go to post John Murray · Mar 17 Also https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls...
go to post John Murray · Mar 17 Maybe the web server that you are connecting to IRIS through isn't configured to allow the WebSocket protocol. For IIS there's some relevant documentation at https://docs.intersystems.com/iris20243/csp/docbook/DocBook.UI.Page.cls?...
go to post John Murray · Mar 17 A useful article, but I have a couple of comments: 1. I think "fallback" is a better choice for the "http.proxySupport" setting than "off", and it should still have the desired effect. 2. I'd like to understand exactly why you find it necessary to make the web gateway connect to IRIS as SuperUser rather than as CSPSystem (the default). On my test environments this isn't necessary, but I'm not using SSL/TLS as the Connection Security Level.
go to post John Murray · Feb 21 This is disappointing, and I don't recall seeing any warning with the earlier 2015.1 previews that at some point we wouldn't be able to upgrade them. Please remedy this by making the next 2015.1 preview version capable of upgrading existing 2015.1.0L instances.
go to post John Murray · Feb 20 Today I was pleased to find a new preview version available, 2025.1.0.204.0, but when I tried to use it to upgrade the one I had previously installed (2025.1.0L.198.0 on Windows 11) the installer stopped with the message "A newer version of IRIS is already installed."
go to post John Murray · Feb 17 Also worth noting that developments in VS Code itself since the original article have added new Git features, so the GitLens and/or Git Graph extensions are arguably less relevant/needed.
go to post John Murray · Feb 11 Your screenshot shows the ObjectScript Explorer view, which was originally created for the client-side development paradigm in which you export to a folder on your workstation the routines/classes/etc you want to change, then manage them locally in Git. You then import your changes to the server that your `objectscript.conn` setting points to (the same place you may have exported them from). In this case you can expand the Routines node of the tree shown in your screenshot, then with focus on that tree press Ctrl+Alt+F to invoke VS Code's tree search/filter widget. Here's a screenshot of me using this to narrow down the large number of INT routines in a VistA namespace: The other development paradigm (server-side) may suit you better if you are migrating from InterSystems Studio. In that paradigm, use the Servers view (at the bottom of your screenshot) to expand the Namespaces node of your server. Then use the pencil or the eye button to add to your VS Code workspace a folders that gives you direct access to the namespace (pencil if editing, eye if only viewing as read-only). Also follow the instructions in the README of the InterSystems ObjectScript extension to enable proposed APIs. Then type Ctrl+P and start entering the name of the routine you want: You can also use the Ctrl+Alt+F tree widget on the VS Code Explorer view of your workspace.
go to post John Murray · Feb 7 What does the "Web Sessions" report on the "System Operation" section of IRIS Portal show?
