go to post Brett Saviano · Jan 15 Hi @Igor Barboza, this was changed for version 3.4.0 in PR #1681. You can view that and the linked issue for more detailed reasoning for the change, but in short we had reports of files being synced to the server automatically with incorrectly generated names. We decided that it would be preferable to avoid that at the cost of the user having to add the class name manually. The cursor will be automatically placed in the correct position in the document though.
go to post Brett Saviano · Jan 2 A REST implementation method can do anything, including Dynamic SQL queries. Do you need to allow arbitrary SQL execution though? If all you need to expose is the data in one table with some filtering you can have an endpoint like GET /epic/master (path is arbitrary) and have query parameters for filtering. The implementation can use SQL to popular the results under the hood without needing the end user to write SQL.
go to post Brett Saviano · Jan 2 @Scott Roth I don't recommend that you use the Atelier API for this purpose. It requires %Development, which is very highly privileged.
go to post Brett Saviano · Dec 16, 2025 @Evgeny Shvarov The Atelier REST API used by VS Code uses the same document representation as $SYSTEM.OBJ.ExportUDL(). It has no trouble saving files that are sent to it in this format. If $SYSTEM.OBJ.Import/ImportDir/Load() can't import that format then I believe that's a bug that should be reported to development.
go to post Brett Saviano · Dec 5, 2025 I think in my ideal world, I would be able to make my own branch for my modifications, make changes, then commit them to the server when ready (thus deleting the branch). But if I want to be able to do that, I think we need to aim for a single-user environment, which means some sort of IRIS instance on my machine, or a dedicated environment just for my new branch on the server (as you suggested), although I don't quite understand how that would work. This process is exactly what I was suggesting. Each developer gets their own IRIS, like they have their own copy of the code in the dedicated branch for the feature. Think of IRIS as the SDK, like the JDK for Java or Node.js for JavaScript. Your setup is complex, but if you have a process to set up your shared dev server then you can have the devs run that to set up their own servers. If developers won't be running tests that require the full setup, then the instance setup becomes even simpler. You can then have a CI/CD pipeline in your git provider that moves code to the shared test instance when it's committed to the main develop branch. With a setup like this, you can have as many devs working on as many projects as you like without them blocking each other. Any conflicts between changes will be resolved when the devs submit their code for a merge/pull request on your main branch.
go to post Brett Saviano · Dec 4, 2025 Hi @Michael Derr, I recommend you have an isolated dev environment for each branch, whether that be a whole server or just a namespace. You can have Embedded Git configured to a different branch in each environment. Developers would then work in the environment that corresponds to the branch. This can be achieved with only server-side source control, but it also sets you up nicely to move to local source control in the future if that's a goal.
go to post Brett Saviano · Dec 2, 2025 @Tobias Krause You need to have a workspace folder with an active server connection to the same server and namespace that you are trying to export from. These checks are there to prevent you accidentally syncing the exported files with a different server or namespace.
go to post Brett Saviano · Oct 24, 2025 Hi @Stephan Gertsobbe, there is no exact equivalent for exporting an entire Studio project in a single XML file. The command I mentioned is the closest approximation. The best workaround is to use a terminal to do the export. Since you mentioned using these exports for backup and that you have server-side source control in use, I would expect that your files being tracked in source control would constitute the backup. Source control support for projects files themselves is limited due to the way we edit them. The Atelier REST API used by VS Code has no support for Studio Projects since the concept didn't exist in Atelier. VS Code uses SQL to modify projects instead. This mechanism was chosen for its backwards compatibility since Studio Projects users tended to be on older server versions. Source control UserActions are fired for projects, but not all of the lifecycle hooks will because we are not using object access.
go to post Brett Saviano · Oct 6, 2025 VS Code has a GUI that will help you debug REST services: https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls...
go to post Brett Saviano · Sep 15, 2025 @Jochen Roese This is a known bug in ExportUDL() that has been fixed in IRIS 2024.1.2+ and 2024.2+. You can work around this by solely using VS Code instead of mixing in ExportUDL(). VS Code does not have the bug.
go to post Brett Saviano · Aug 5, 2025 @Jeffrey Drumm The Lite Terminal does not support aliases and does not support command history in the SQL shell (or any Read-based input). Please open an issue on GitHub for the text duplication issue when the first charater is a colon.
go to post Brett Saviano · Jul 15, 2025 Hi @Neil.Thaiss451, the inactivity timeout for the new applications is currently hard-coded and cannot be configured by users. We have received feedback that users would like to configure the timeout, so we are looking into the best way to expose that functionality for all our new apps. We hope to address this feedback in a future release. Thanks for trying out the new apps!
go to post Brett Saviano · Jun 26, 2025 @Cristiano Silva This is a bug. I have opened PR #1599 with a fix.
go to post Brett Saviano · Jun 16, 2025 @Matjaz Murko I just released version 3.0.3 of the vscode-objectscript extension, which contains a fix for this issue.
go to post Brett Saviano · May 29, 2025 For anyone else who may be interested, here is my answer to @Ricardo.AlvesdosSantos's question that I provided on the GitHub Discussion he opened: The extension intentionally doesn't support what you want to do. You have to pick a side. Since you're using Git and are happy to edit the files on your local file system, I suggest you turn off source control on the server and fully embrace the client-side editing workflow. Your local file system will be the "source of truth" and the extension will sync files with the server on save and compile them. The only change is that instead of using IRIS to run the source control actions, you can use any number of industry-standard Git-compatible tools. VS Code works well with Git out of the box, and there are additional extensions you can install to make that experience even better. You can also use a different GUI application like GitHub Desktop or Sourcetree, or the git CLI directly.
go to post Brett Saviano · May 28, 2025 Try responseData.items.%Get(0).titles.%Get(0).value.%Get("en_US") or responseData.items.%Get(0).titles.%Get(0).value."en_US".
go to post Brett Saviano · May 9, 2025 If you're expecting those keys to be defined in the first element of the "items" array like the example code, you can do this: If responseData.items.%GetTypeOf(0) = "object" { Set pResponse.COMPortalURL = responseData.items.%Get(0).portalUrl } This assumes that "items" will always be present and be an array. It checks if the first element of "items" is a nested object, and then sets the target object property to the value of portalUrl in the nested "items" object. You don't need to check if portalUrl is defined since referencing an unassigned key in a %DynamicObject will return the empty string instead of <UNDEFINED>.
go to post Brett Saviano · May 5, 2025 @Juan Mota Sanchez Is your instance set up for minimal security? If so, you need to change the /api/interop-editors web application to allow Password authentication. It's a known issue that the new Interoperability UIs don't support unauthenticated access. This will be fixed in a future version of IRIS.
go to post Brett Saviano · May 1, 2025 The next versions of the three extensions (vscode-objectscript, Server Manager and Language Server) will attempt to close their web sessions when VS Code shuts down. This should help avoid sessions stacking up if you restart VS Code often.