The ComplexDelete classmethod uses the FileSet query:


ClassMethod ComplexDelete(filename As %String, Output return As %Integer) As %Integer
{
    Set resultset=##class(%ResultSet).%New("%File:FileSet"),return=0
    Do resultset.Execute(..GetDirectory(filename),..GetFilename(filename))
    Set exit=1
    For {
        Quit:'resultset.Next()
        Set file=resultset.Data("Name")
        Set r=$$$FileDeleteRet(file) If r,exit Set exit=0,return=r
    }
    Quit exit
}

The problem is, that query treats ";" as a delimiter separating multiple search patterns.

You could replicate the method but specify another delimiter (e.g. comma) when you Execute the query to get the resultset (untested code):

Do resultset.Execute(..GetDirectory(filename),..GetFilename(filename),,,",")

Maybe someday ISC will enhance ComplexDelete to take an optional delimiter argument.

Bear in mind that local variable arrays can hold orefs but PPGs cannot:


SAMPLES>w $zv
Cache for Windows (x86-32) 2017.2.2 (Build 865U) Mon Jun 25 2018 11:10:00 EDT
SAMPLES>
 
SAMPLES>s oP=##class(Sample.Person).%OpenId(1)
 
SAMPLES>w oP.Name
Gallant,Yan N.
SAMPLES>
 
SAMPLES>s LocalArray(1)=oP
 
SAMPLES>s ^||PPG(1)=oP
 
SAMPLES>w LocalArray(1).Name
Gallant,Yan N.
SAMPLES>w ^||PPG(1).Name
 
W ^||PPG(1).Name
^
<INVALID OREF>
SAMPLES>w $isobject(^||PPG(1))
0
SAMPLES>w ^||PPG(1)
1@Sample.Person
SAMPLES>
 
SAMPLES>w LocalArray(1)
1@Sample.Person
SAMPLES>w $isobject(LocalArray(1))
1
SAMPLES>

After a couple of maintenance releases this week we're now up to version 3.0.5. The recent changes:

  • Improve performance when opening documents from namespaces containing a large number of items.
  • Switch to Explorer view after 'Add Folder to Workspace' command.
  • Make 'Never' option of license message work as designed.
  • Check keyfile on initial connect.
  • Key request email body lacked linebreaks.
  • Add a clipboard-copying alternative to the option that attempts to compose a key request email.
  • Add client DN to message when certificate check fails.
  • Avoid affecting MRU records of a connected Deltanji.
  • Support binary web app files.
  • Cater for text files without terminator on final line.
  • Malformed serverAddress setting prevented Serenji from connecting to Deltanji.
  • Skip web apps that have a dispatch class defined.
  • Web app files in subdirectories more than one level deep were not listing.
  • When not using Cache authentication, userid in new document template was wrong.
  • Web app files written into an unmanaged namespace via the pkg:// notation were being set readonly.
  • Clear previous VSCode Problems entries when fixing CSP compile errors.
  • Fix unreliable behaviour when ephemeral ports are being used.

If you want your Ensemble development team to work collaboratively in shared namespaces on a common server Git probably isn't a good choice for source control. Are you committed to using Git? Have you looked at our Deltanji product? It's integrated with Studio, and with Atelier, and also with our Serenji extension for Visual Studio Code. It's able to handle code deployment as well as versioning. It also supports scenarios where developers work in their own namespaces (whether on a shared server or on their local machines).

I agree, but unfortunately Portal's edit forms for config items always apply settings  into the production class (the XData block). Even worse, Portal ignores the source control status of the production class, so you can't prevent these changes. Portal users have to go elsewhere to add/edit System Defaults values. It's far from obvious, nor is it easy. And because they don't have to (i.e. the users can just make the edit in the Portal panel and save it) nobody does. We raised all this years ago, but so far it's remained unaddressed sad

See also https://community.intersystems.com/post/system-default-settings-versus-p...

I've checked that it compile, is synchronized server-client and vice versa.

Is this referring to when you're using the Serenji extension? If so, understand that there is no client-side copy of your code (so no synchronization involved). Serenji works directly on your server-side code.

It's good. Only I'm missing the intellisense

Yes, Serenji doesn't yet do a good enough job of providing Intellisense. It's on our roadmap.

Did you intentionally start your Serenji service process on port 43221 rather than the default port, which is 43211?

You can check the status of that service process by running this command in a Cache Terminal:

D ^%Serenji

The output includes  a section like this:

Serenji explore/edit/debug service
----------------------------------
 Service status: Running
   Primary port: xxx
   Aux port min: xxx
   Aux port max: xxx
 Server address: xxx

Version 3.0.3 has just been published. Main new feature is support for web app files (CSP, CSR and other text types). These appear in the tree under the package associated with the app:

Other changes:

  • Initialize standard workflow for embedded Deltanji (new installs).
  • Interoperate better with Studio locking scheme.
  • When launching debug, default namespace and program based on current document.
  • Recover from connect failure (e.g. bad password).
  • Report version mismatch between extension and server.
  • Offer to compose email requesting debug evaluation key.
  • Incorporate service stop / start into install / upgrade method.
  • Prepare for VSCode 1.34.
  • Prepare for upcoming Deltanji extension.

My guess is this is on Windows, and the Windows service that HealthShare runs as is configured to Log On As a specific Windows account. Check those credentials. Perhaps the password has been changed, or the account has expired, or been disabled. Look in the Windows event logs (probably the Application one). Another source of info is the cconsole.log file in the mgr subfolder of wherever you installed HealthShare.

Your problem doesn't seem likely to be specifically related to Cache Studio.

We just published 3.0.2. If you already installed 3.0.0 your VSCode extension should upgrade automatically next time VSCode checks for extension updates. Or you can trigger that from the "..." menu on the Extensions viewlet. For best effect you should also upgrade the server-side part wherever you've previously been connecting from 3.0.0.

Changes in 3.0.2:

  • Upgrade embedded Deltanji to version 7.0.
  • Support networked Deltanji Enterprise edition environments.
  • Automatically add embedded Deltanji aliases for new usernames.
  • Report permission problems at connection time.
  • Support prompting for username at connect time.
  • Remove 'Preview' flag from Marketplace entry.
  • Improve documentation.

Serenji is also listed on Open Exchange.