That shouldn't matter since the tasks themselves are not always stored in the namespace in which they are run. They are stored in IRISSYS. Does the user you are logged in as have permission to edit the %SYS.Tasks table in the IRISSYS namespace? And is this a system task? (System tasks cannot be deleted.)
If you use a dataCombo, the first column of the SQL query is the actual value of the dataCombo and the second column is the display value. So if you defined a dataCombo with sql="select Analyst, Analyst->Name from Analysts" (or whatever your table is) you'll get what you want.
In that case, you'll also want to define the sqlLookup property of the dataCombo. That tells the Zen page how to find the correct display value when the value of the control is changed programatically, so something like "select Analyst->Name from Analysts where Analyst=?"
Does $ZV not meet your needs? I see you used it for your post, and it includes the build version, too.
Inside your combobox, you can define a displayList and valueList. If you do that, you don't have to also define the options individually.
Thank you, Guillaume! Lesson learned: make sure you're running pip from the IRIS Python, not the default Python on the PC!
Performance is number one for us. With properly defined and tuned tables, I've never seen a database run its queries faster than IRIS.
Also just a lot of native capabilities. It's pretty rare that we have to reach outside of what comes in the box. And now with embedded Python, when we do need to add something, we have a lot of options.
Aside from Python's technical benefits, there's also a personnel consideration. More and more younger developers are learning Python, and according to the PYPL index Python passed Java in popularity among learners in 2018 and is far beyond Java today. That means having Python as an option opens up your hiring pool more than any other language to the next generation of developers.
Yes, you can do that, but I have another recommendation.
You generally want to be careful with what you do in %SYS, and you might not want a user to have permission to access that stuff all the time. You could create a new security role that gives the right permissions to access whatever you're accessing, then assign it in that method, run the code that needs it, and remove it. So let's say your new security role is called MyRole:
set$ROLES = MyRole
set oldns = $NAMESPACEnew$NAMESPACEset$NAMESPACE = "%SYS"// Do your stuff here.new$NAMESPACEset$NAMESPACE = oldns
new$ROLESThe $ROLES special variable is used to manage roles that are added and removed programatically during the execution of code, but does not affect roles assigned to the user in the management portal.
If you don't have any other criteria you can use in your where clause, that will happen. Based on the data you've shown us, you'd need either ProvId or ProviderType to get it down to 1 row.
If you just want the first row returned and don't really care which one it is, you could do
SELECT TOP 1 IdentityId
FROM PhysTable
WHERE ProviderName = 'DOE, JOE' AND Type = 'NPI'
ORDER BY IdentityIdBut that's only if you always want the lower number, and I doubt that's the case, right?
I think I'm confused. In your previous comment you said "We do not get the ProvId "8252" in the message, we do get the IdentityId "345678"." So I thought you got the IdentityId in the message.
What if you just do SELECT IdentityId FROM PhysTable? Do you get a column, or nothing?
So you get the IdentityId and the ProviderName, and you know the Type, and you want to write a query to get the ProvId?
Do you mean you want to know how to get just that column?
SELECT IdentityId
FROM PhysTable
WHERE ProviderName = 'DOE, JOE'ANDtype = 'NPI'AND ProvID = '8252'Or if this is in SQL embedded in ObjectScript:
&sql(SELECT IdentityId INTO :IdentityId FROM PhysTable WHERE ProviderName = 'DOE, JOE'ANDtype = 'NPI'AND ProvId = '8252')That will get the Identity ID and put it into the variable IdentityId for you to use in further code.
If you test the connection in your System Management Portal, does it fail there too?
What error text are you seeing when you try that?
InterSystems Studio is deprecated. IRIS 2024.1 is the last version that ships with the Studio, but it can be downloaded as a separate component from the WRC.
Neither text nor CSV files support any kind of formatting, just plain text.
When you're using a REST API, you're sending an HTTP or HTTPS response, so all of the typical HTTP headers apply. This includes the content type and the disposition header. The content type, as Rodolfo mentioned, can be set using %response.ContentType. Others can be set using %response.SetHeader.
Just FYI, CSP sessions are instances of %CSP.Session. You could do ##class(%CSP.Session).%OpenId("wuuZ2Gwgxw") to get the session and use some of the properties and functions there to get more information on what's going on. And since they extend %Persistent, you can also use %DeleteId (at your own risk, of course).
If you are looking for the class name where a currently-running method originates, you could also try:
set method = $CLASSNAME($THIS)_"||"_$P($Stack($stack,"PLACE"),"+",1)
&sql(select Origin into :origin from %Dictionary.CompiledMethod where ID1 = :method)
w origin,!Are you trying to get all of the classes that a class extends? You can do that like this:
set classname = $CLASSNAME($THIS)
&sql(select primarysuper into :super from %dictionary.compiledclass whereid=:classname)
w super,!If you do that, super is a ~ separated list of the class and everything that it inherits from, which is probably actually more information than you need.
Thank you, Brett! That's exactly what I was looking for.
Glad you got an answer to your main question. To answer your other question about how to check a status, the Execute and Prepare methods of the %ResultSet class return a %Status. Where you have do Rs.Prepare(SQL) and do Rs.Execute(), you could use:
set sc = Rs.Prepare(SQL)
if$$$ISERR(sc) {$$$ThrowStatus(sc)}
set sc = Rs.Execute()
if$$$ISERR(sc) {$$$ThrowStatus(sc)}Then if there was an error doing either of those things, it would get passed off to your catch block. In your case, there would've been an error indicating your permissions issue.
No, it doesn't run as soon as the previous task ends. It runs at the next scheduled time. So in my example above, if your task runs at 12:00:00 and doesn't finish until 12:01:30, the next scheduled time is 12:02:00, so that's when it'll run next. I'm not sure how far back in versions this goes, but you might be able to change that behavior so it's more like what you're expecting.
A task expires if it can't run when it was scheduled. This could be because your Ensemble instance was down when the task started, or it could be because a previous instance of the task was still running when it was supposed to start again. For example, if you have a task set to run every minute but it takes the task 90 seconds to complete, then when it run at 12:00, it will be supposed to start again at 12:01, but since it will still be running, the 12:01 task will expire and the task will run again at 12:02.
Also note that if you do it this way, your tag for the custom component will be RC:imageclickbutton with the XML namespace and a colon on the front.
There isn't a consistent mapping for everything, but if you're in the %SYS namespace, you can query the tables %SYS.Task and %SYS_Task.History to find these specific things. Some of the security related things are in the Security scheme, like Security.Roles and Security.Users.
When you're in the SQL part of the system management portal, if you check the box to show system tables on the left, you can see a lot of these then under tables, and you'll be able to guess what a lot of them are just based on the names.
You haven't added your hgroup to your page anywhere. You'll need to figure out what its parent element should be and use the %AddChild method of that Zen component to add the hgroup somewhere, just like you added your maxData to the hgroup.
And it's not only on the development end. It's also when you're educating and training. With Zen, it was all about ObjectScript and defining a class, plus a little javascript here and there. You didn't have to devote extra training and learning to the second system.
Rich, I understand all of that. Why, though, do answers to those of us who like Zen always including language like:
". . . could never hope to reach feature parity with more broadly accepted frame works like Angular and the others listed above . . ."
". . . that could never achieve feature parity with those mass market offerings. . ."
I know I'm newer than a lot of people here, but I have yet to see anyone asking about Zen asking for feature parity with any of those other front ends. Meanwhile, the part that actually matters gets discounted:
". . . could only beat them in providing faster, more efficient access to the data layer."
There doesn't seem to be a very good understanding of why some of us are still as attached to Zen as we are (other than momentum). That fast, efficient access to the data layer is extremely important, and we like being able to handle the front end and back end together, seemlessly writing the code it takes to do whatever we need to do on both at once. Zen also allowed us to do all of this using the same skill set that we used for everything else in our projects instead of having to learn two entirely different things for the front and back.
Absolutely none of this has anything to do with a desire for something Zen-like with all the bells and whistles of something like Angular.
As Robert said, the data and indexes are both stored in global trees. The structure of the trees for indices and the trees for general data storage are different, though, and that's where the efficiency comes from.
The data will be stored in the ^EMPLOYEED global. You'll see a bunch of data in that global like:
^EMPLOYEED(1) = $lb("001","ABC",20)
^EMPLOYEED(2) = $ib("002","AAA",21)
Those are lists of every property of that class, indexed by the ID column.
The indexes, on the other hand, will look more like:
^EMPLOYEEI("IDX_EMPID","001",1)
^EMPLOYEEI("IDX_EMPID","002",2)
This allows for a much more efficient search to find the ID of the records that match your search criteria, similar to if you opened a terminal and put in:
write$ORDER(^EMPLOYEEI("IDX_EMPID","001",""))Which would give you row 1, then it could more easily look up row 1 in the original without having to go through every record in the table in order searching for it.
In your system management portal, you can run your query and check the query plan, then run it again telling it to ignore indexes like this:
SELECT * FROM %IGNOREINDEX * EMPLOYEE WHERE EMPID="005"This will tell it to ignore all indexes on the table. You can check that query plan and compare it to the original to see the differences in how the query finds data and how well it performs.