Keren, great, thanks - this has allowed me to see the content of the messages and I can dig further.

Thanks, yes, this is what it needed to be - got there myself, as it happens, but thanks. Documentation wasn't very clear. 

Carmen, thanks, that's really helpful. If we need further information we'll reach out - as is so often the case, I'm doing some technical investigation for a development that may not ever be tackled, or may be tackled in a different way, or whose specifications will change wildly before we tackle it, or...!!!

Alex, thanks. Yes, license is still valid. And no, not possible to suspend before changing problem item - getting databases locking errors when I try. No idea how we managed to corrupt this quite so thoroughly!!

Thanks Alexander. Terminal Task Manager:

• can delete other tasks, but
• trying to delete the "corrupted" one get: "ERROR #5803: Failed to acquire exclusive lock on instance of '%SYS.Task'" (same as when using Management Portal)

Re figuring our where system tasks are stored via journalling, I understand the principle of what you are saying but we are probably reckoning the effort in doing that at least as great as scrubbing and reinstalling - we lose some config (we've got it documented, but the developer who did it originally has left), but no important running code.

Thanks. Not sure how to do all the things you suggested (1 or 3), but tried (2) using the Scheduled Tasks page in management portal. Couldn't suspend or delete the problematic task - getting SQL errors about not being able to lock or access a table.

Thanks. Not sure how to do all the things you suggested (1 or 3), but tried (2) using the Scheduled Tasks page in management portal. Couldn't suspend or delete the problematic task - getting SQL errors about not being able to lock or access a table.

Thanks for suggestion, but we already know it affects all namespaces 😥

That looks ideal, thanks! Almost like it was designed to do the job we are looking for...! 🤣 Will investigate properly for our specific situation.

Turns out it wasn't git's fault - though really helpful for us to clarify what git is doing, and ensure we have a decent set of default .gitattributes set...

We don't fully know what is going on, but ALL DTLs on one Ensemble instance throw this error, on load in Management Portal or compile via Studio or VS Code - can't even create a new DTL. So we are currently suspecting some kind of corruption/error on that server, rather than something related to the code we are bringing from git. But no idea what has gone wrong. Its a dev server - we may just scrub it and reinstall...

Thanks @Evgeny Shvarov. Unfortunately can't use Iris yet - maybe at some point in the future - but a useful extra benefit when we do make the transition. 

Thanks Cristiano. I'd found the page you linked to before, but its not very explicit about uninstallation!

Would I be correct in interpreting it as:

• only uninstall option is the unattended section at https://docs.intersystems.com/ens201817/csp/docbook/DocBook.UI.Page.cls?...
• would I be correct to interpret 'CacheC' in the example command as the instance name of the Ensemble installation to be uninstalled? Or is that the folder name on the filesystem where it is in installed?
• Not familiar with Windows Registry editing, so can I safely delete those two trees in the registry if i want a completely fresh start?

Thanks!

Thanks all for responding. Really only adding this message so I can try and mark the question as answered - since there are the two approaches (ompare and using git/repo tools), not wanting to mark one or other as the answer, since both have merits and may be helpful for different situations. I suspect we'll try the git/repo tools approach first, given our particular mix of platform and experience.

Thanks for suggestions so far.

One challenge is our organisation is very wary of installing any additional code (as Alex suggested) or hooking up something like VS Code, to the live server, which is passing patient information between the various hospital systems... The test system has a little more flexibility, but organisation is a bit twitchy!! Would a plausible path be to sort of follow Eduard's suggestion, but:

1. Export code from live (an export of the classes via Management portal, or if better an export via Studio) to XML
2. Export code from test (as above) to XML 
3. On a local laptop, import live code to a newly created namespace and commit from there to a GitLab repo
4. On same local laptop, import test code and commit from there to the GitLab repo
5. Compare as suggested....

Shamus, thanks, works perfectly. Much appreciated.

Thanks Ben, good start for a conversation in our team...