John Murray · Jan 30, 2017 go to post

I'll repeat what I wrote on the previous DC thread you opened about this issue:

I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

John Murray · Jan 30, 2017 go to post

Please clarify what you mean by "browse the file contents".

Are you opening c:\TEMP\SoapTree.xml in a text editor?

Maybe that editor is assuming that the file is UTF8-encoded.

Can you view it in a tool that shows you the byte values it contains?

Did you have a particular reason for choosing to write the file using an instance of %Stream.FileBinary instead of %Stream.FileCharacter?

Also, be aware that the WebMethod classmethod of %SOAP.WebBase is tagged as "Internal" and commented thus:

/// This method is used internally by Caché. You should not make direct
/// use of it within your applications. There is no guarantee made about either
/// the behavior or future operation of this property.
 

John Murray · Jan 26, 2017 go to post

I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

You might need to open a support case with WRC. I don't work for InterSystems.

John Murray · Jan 26, 2017 go to post

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.

John Murray · Jan 26, 2017 go to post

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.

John Murray · Jan 17, 2017 go to post

%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 .

John Murray · Jan 9, 2017 go to post

Aha! I have changed those two settings and I now see the extra columns of checkboxes.

John Murray · Jan 9, 2017 go to post

I got a couple more of these over the weekend, despite having checked and altered my settings per your other post:

John Murray · Jan 9, 2017 go to post

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.

John Murray · Jan 9, 2017 go to post

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é.

John Murray · Jan 6, 2017 go to post

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.

John Murray · Jan 5, 2017 go to post

Thanks for doing that. The DC forum software didn't allow me to answer my own question.

John Murray · Jan 5, 2017 go to post

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!

John Murray · Dec 19, 2016 go to post

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?

John Murray · Dec 19, 2016 go to post

Sorry to hear about your experience with Deltanji. I've not been able to find any sign that you contacted us at George James Software for assistance. Given the chance, we're generally helpful folk.

John Murray · Dec 16, 2016 go to post

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.

John Murray · Dec 13, 2016 go to post

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...

John Murray · Dec 13, 2016 go to post

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.

John Murray · Dec 7, 2016 go to post

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.

John Murray · Dec 6, 2016 go to post

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.

John Murray · Dec 6, 2016 go to post

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.

John Murray · Dec 1, 2016 go to post

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:

John Murray · Nov 22, 2016 go to post

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.

John Murray · Nov 21, 2016 go to post

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?

John Murray · Nov 17, 2016 go to post

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.