Thanks @Benjamin De Boe 

I believe we are on a high enough version which should cater for this.

w $zv

Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2017.2.2 (Build 865U) Mon Jun 25 2018 10:50:02 EDT

Hi Rupert, 

I hope you are well and enjoying robotics. 

Thanks for coming back to me.

Your recommended approach, though hugely appreciated, won't work for me I'm afraid. 

In answer to your questions:

  • I am making my call from object script, as part of an already built component within a financial cache application that explicitly uses a SELECT statement
  • Changing this component to use CALL instead of a SELECT is not possible due to dependencies and legacy code.

Essentially question I am asking is why some stored procedures can only be called via CALL and why can some be called by both CALL and SELECT (such as in the case of class queries)?

I get a feeling this has something to do with SQL-Invokable-Routine (SIR) - see @Dan Pasco comment here but there is almost nothing in the documentation or any code for me to go further on.

Fantastic post @Eduard Lebedyuk 

Alternative approach: %SQL.CustomResultSet is icing on the cake which is not covered by Intersystems documentation. It really should be. This is exactly what I needed for my current project. Thanks.

Fantastic help. Thank for sharing this. I didn't know you could use ##Expression in basic class queries. Studio does complain about it though but works just fine at run time!

It seems that views in cache need to start with a "SELECT ..." therefore to get around this, I did the following which works: 

Class DC.NewClass1 ClassType = view, ViewQuery = {
SELECT '', As A, '' As B WHERE 1=2


SELECT A,B FROM DC.ClosedFuturesProc(65257,65286) --'2019-09-01','2019-09-30'
} ]
{ Parameter READONLY = 1; }

Thanks John. Appreciate your team's effort in getting us to this stage. We will upgrade and start testing it out. 

LUT and HL7 need to be on the roadmap at some point. Our code is currently fragmented and not entirely committed to GIT. Changes to these files need to be manually tracked which defeats the purpose of having a source control system.

Thanks again. 

@Andreas, are we on track for Atelier 1.3 release late August or has this moved?

Atelier is starting to become critical to our way of working and we are hoping it will address some critical issues such as 1.2's inability to export HL7 schemas and lookup tables.

Please provide an update?

Can anyone provide an update on Atelier 1.3 release date? It is scheduled for release this month.

There are quite a few issues we are hoping it would fix hopefully around DTL errors and inability of 1.2 to export HL7 schemas and lookup tables to commit in GIT