My guess is that your pInput stream contains XML encoded as UnicodeLittle characters.
The left single quote character is unicode codepoint 8216 decimal which is 2018 hex. In UnicodeLittle this gets transposed and the 0x18 comes first, followed by the 0x20.
What is the nature of the failure?
Perhaps when you save your LUT changes there's a small time window during which no LUT entries exist. This is pure speculation on my part, as I haven't investigated. But if it's true then I can imagine this could cause problems in the production. In which case, perhaps you need to suspend at least the relevant parts while you save the change.
%Admin_Task is a Resource, as are %Admin_Manage and %Admin_Operate.
In contrast, %All is a Role.
Access to SQL tables is controlled either at the Role level or at the individual User level.
If your user has permissions on the %Admin_Task resource because they hold a role, then it may be appropriate to grant the necessary SQL permissions to that role. By doing this, anyone else holding the role will also be able to access the table.
To grant the SQL permissions, edit the role (or user) definition. Go to the "SQL Tables" tab. Set the namespace dropdown to "%SYS" and check the box to include system items:
In my example above the %Operator role has no permissions on SQL tables in %SYS.
Use the Add Tables button to add a row that gives this role permission to perform a SELECT on the %SYS_Task.History table .
Aha! I have changed those two settings and I now see the extra columns of checkboxes.
I got a couple more of these over the weekend, despite having checked and altered my settings per your other post:
Thanks Eduard. I'd add, this has to be done from the %SYS namespace.
I think this limitation is unfortunate. Encountering the "Service unavailable" when you're trying to evaluate Caché for the first time might discourage you from continuing.
Quick'n'dirty way is to edit the cache.cpf file and then reactivate the config change. Simplest way to reactivate (though not always convenient) is to restart Caché.
My page looks different:
As well as not having the extra checkboxes your screenshot shows, mine are all unchecked but I still get the notifications.
Thanks for doing that. The DC forum software didn't allow me to answer my own question.
Thanks for the information Jamie. At the time I posted the question I don't think this level of back-compatible implementation of Studio's existing mechanism was available. I'm pleased to confirm that in the Atelier 1.0 release our existing add-ins "just work". Well done team!
A new set of keys was published yesterday at the Field Test page.
Is the E: drive a real local drive, or is it a mapped driveletter intended to give you access to a folder shared by another machine?
Also, the $ZF calls made by Studio via your source control class will operate with the server credentials that the InterSystems superserver (port 1972, typically) uses. On Windows that's the logon account of the Caché/Ensemble/HealthShare service. Whereas when you launch a Caché terminal onto you local instance from your Windows desktop, your $ZF calls will use the credentials you logged in to the Windows desktop with. Similarly on non-Windows platforms.
It looks to me like DC is integrated with ISC's SSO mechanism. SO maybe that's what's timing you out. Or perhaps if you log out from something else that uses SSO it affects your DC session? Just speculating...
One way is to create a SYSTEM^%ZSTART subroutine and put some COS code in there. Read the doc here about how to do this.
Take care to read the documentation carefully. For example, if your SYSTEM^%ZSTART causes an error your environment startup could fail. Here's a simple error handler to wrap your startup actions in:
try {
// Your code here
}
catch e {
d ##class(%SYS.System).WriteToConsoleLog("SYSTEM^%ZSTART error: "_e.AsSystemError(),,1)
}Also note that if you are using InterSystems mirroring you may want to run your startup code only on the primary. In that case I recommend creating/editing the ZMIRROR routine in %SYS (on all mirror nodes) and using its NotifyBecomePrimary entrypoint instead of SYSTEM^%ZSTART. Another benefit of NotifyBecomePrimary is that it only runs after the databases are ready to be written to. In contrast, in a mirroring configuration SYSTEM^%ZSTART runs at a point where the databases are readonly.
Is it just me, or does the screenshot in Tim's post seem unconnected with his text? The one I'm seeing is of the Available Updates dialog of Atelier.
Manoj, I respectfully suggest that your response isn't an answer to Sansa's question, but instead it is a comment on the question. I encourage you to use the "comment" link below a question in future in this kind of situation.
Also, our question here seems to be the same as Sansa's. Are you and Sansa perhaps working on the same project? If yes, coordinating your efforts to post a single question could be useful. In some cases you may even discover your own answer as you discuss the problem, saving you the trouble of posting a question here. In that case you might still choose to post an article sharing a tip with the community.
I'll echo Katherine and say I don't think 5.0 provided that capability directly. Perhaps your 5.0 instance tied telnet logins to your own app-level authentication routine. In that case, you could be doing this kind of thing . For example, using $ZIO to discover the telnet client's address or hostname.
Please also note that there's no Cache version 2016. Rather, there are 2016.1 and 2016.2. Some things available in 2016.2 won't be available to you if you're using 2016.1 (though nothing likely to be relevant to this specific question). I recommend you (and anyone posting on this forum) specify at least the second piece of the version identifier. Even better, give us your complete $ZVERSION string.
No, you'll need HealthShare 2016.2 at least.
Excellent! Congratulations to the team.
Incidentally, there are already some Eclipse updates available for the standalone version. Here's what "Check for Updates" offered me when I ran it right after install (having first uninstalled the beta and deleted its directory):
And when I went ahead with these updates I got the following security warning about a couple of InterSystems components:
Another benefit of doing it the way Tim suggests is that the links will be visible in diagrams produced by tools such as Umlanji and Caché Class Explorer.
I think you stand a better chance of getting responses to this if you move it to the HealthShare group and tag it with a HealthShare-related tag. The "Developer Community" tag and the "Developer Community Feedback" group are intended for posts/questions about the DC forum itself, not the InterSystems products. Posts tagged/classified like that don't appear on people's general new feed, AFAIK.
An interesting article, but I'm puzzled by your use of the term "I11n". I'm familiar with "I18n" as an abbreviation for Internationalization (because there are 18 letters between the "I" and the "n". Likewise, I understand "L10n" as standing for Localization. Some Googling suggests that "I11n" is short for Introspection. Or have I missed something?
And OMI (Open M[UMPS] Interconnect) too?!
A very interesting article Alexey.
One minor observation: you wrote "ECP, or distributed cache protocol, ...". It may be worth saying that ECP stands for Enterprise Cache Protocol (AFAIK). Before ECP InterSystems had a similar thing called DCP, which stood for Distributed Cache Protocol.
I've been informed that development request #143868 has been raised about this. If you'd like to add your voice to those trying to get this sorted out please click the green "thumbs up" on my original post. Better still, lobby for it through your account manager or via WRC.