Thank you Gilberto!

Any idea what resource is required to do this?   Is it just granting UPDATE rights on the Security.Users table?  Or is there a DB Role (limited - not %All or something crazy like that) which will allow this to be run?



You really should work with your InterSystems account manager and  Sales Engineer to look into the details.  This really isn't a forum that covers the TrakCare  product.

All the best!


Sounds like it's necessary to start fixing some bugs if there are that many errors thrown ;)

Is this more for debugging / tracing data that you are generating that volume of events?

Kumar ... I reached out to your account team and they are setting up a call so we can discuss this directly.  We'll help you find a good solution for this!

Also, Classes lend themselves much better to programmatic access and manipulation of their content (you can do this with routines too but it is harder to do so due to their unstructured nature).

For example, the server-side Source Control hooks we use can programmatically insert an RCS Keyword as a class parameter ("SrcVer") into any class which doesn't already have it defined.   This is extremely powerful because it allows source control to create an automatic 'watermark' in every class created for our internal applications which can be programmatically access or from terminal:

SSO>write ##class(AppS.WebClient).#SrcVer
$Id: //custom_ccrs/us/ISCX/SSO/BASE/cls/AppS/WebClient.xml#6 $

This would require much more plumbing to do automatically with a routine!

Making further changes to the SMP banner isn't supported unfortunately.  


It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct?  If so, you are bound to experience frustration with this due to consistency issues.

Please review which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:

If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.

John - thank you for the update on this one.   The request# hadn't been on my radar but now it is and I am seeing what I can do to escalate internally (no promises though).