Try using the errlog parameter, something like:

w $SYSTEM.OBJ.CompileAll(,.err)

Then you can pull the errors from the err variable and put it into a file however you want, for example using %Library.File.

Hope that helps!

Hello Scott,

Thank you for clarifying. HealthShare Health Connect 2019.1 is built with IRIS so it will not accept a Caché online backup. A CACHE.DAT file can be renamed to IRIS.DAT to be used by IRIS which is documented in the IRIS adoption guide.

You need to be on HealthShare core 15.03 or later to take advantage of the in-place conversion for HealthShare Health Connect. I believe HealthShare Health Connect built with Caché 2015.2.2 is not a new enough HealthShare core version.

Outside of that, it may be possible to manually convert to InterSystems IRIS but I presume that would be more effort than going through two supported upgrades.

Hello Scott,

I'm not sure of the full background and context of your upgrade process so I would definitely recommend running this by your sales team, who might refer you to the WRC.

A normal Caché based HealthShare to Caché based HealthShare upgrade won't affect your user databases so why do you need to restore backups at all? What kind of databases are you concerned about? Through your upgrade process won't the databases be preserved and converted as necessary? You can then compile after the conversion.

Have you reviewed the IRIS adoption document available on the WRC distributions page, and have you received a copy of the Health Connect conversion guide from the WRC or your sales team?

Hello Reinhard,

Using Sample.Person I just did a quick test and switching the order of the where clauses did not effect either performance or the query plan.

Some people design or generate very complex SQL queries so I'm not certain if this holds true in all cases (though I agree I would expect it to - if not it may be worth reporting to InterSystems!). If you are interested in comparing performance and query plans this is pretty easy to do from the System Explorer > SQL page in the system management portal.

Hope that helps!

Hi Scott,

I'm not aware of an easy way to access the older HealthShare or Health Connect documentation. If you need those docs it might be a bit of extra effort but you can install a kit with the version you want to review and access the docs that way.

If you're specifically looking for an online solution then I'm afraid I don't have an answer for you.

What version of Caché are you attempting to install? Windows 10 began being supported with Caché 2016.1.

Given that there was an incomplete install I would recommend uninstalling Caché, restarting, and then trying a fresh install.

For posterity:

On a minimal security install unauthenticated access is the only authentication method enabled for most services. We document the risk of modifying roles for UnknownUser (used for unauthenticated access) and cover some other security considerations here:

If you end up in a situation where your security settings no longer allow you to access Caché, you can use emergency startup mode as documented to log into Caché and fix your settings:

Much appreciation to my colleague Jon who walked through these steps with Joshua.

Hello Zdeněk,

The answer to your question probably depends on the specifics of what you are trying to do and what your constraints are. Is there any consideration to combining the two installer manifests into one? In your previous post you mention an unattended install, so I assume this is related to the .cmd file you are attempting to create. I wasn't aware that an unattended install could run multiple manifests; is that possible or are you running the second manifest manually?

You could use conditional <If> tags in the installation manifest if you wanted to perform some verification. You could use <Invoke> to run whatever method you want to confirm that your first manifest was carried out. For example, you could write and import a simple method that leverages $SYSTEM.OBJ.GetClassList to check that your classes exist. If your method isn't able to run that would also be evidence that the first manifest did not succeed.

%SYS.Namespace.Exists would confirm whether a namespace exists.

Alternatively, you could use the <Log> functionality of the installer manifest and then read the log.

Hope that gives you some ideas! I did see that Dan Kutac replied to one of your other posts - it seems like he is working with you on your manifest so I think he would be able to help you with this.