Attention, I am now advertising on my own behalf ;-)
You can do that very easily with Caché Monitor

Caché Monitor connect via TCP to Caché\IRIS (like the ODBC driver).


David thanks for detailed post! I've question about "When the Caché Spark connector is released, Spark-based applications will be able to make full use of Caché as an open analytics platform".

Did you have any details about plans from Intersystems to develop a "Caché Spark connector"? Links about that? Thanks!


I'll created a fork on github ( for Apache Zeppelin. My plan is to create a Caché Interpreter (first JDBC based) to learn and unterstand the architecture of Zeppelin.
After this it would be great to extend this Interpreter to allow to query the Caché Data via COS. For this I'll contact the "Caché Web Terminal" guys maybe they can help...
All are very welcome support this open source Interpreter. So feel free to jump in and support this project by coding, idea, testing ... or what ever ;-)

Thanks Benjamin!

Yes I've checked the sourcecode to see how a interpreter is done. It looks not like rocket science.. probably I've not completely understand the details, so I can say that ;-)

But! ... I have no idea which functionality would be helpful in an more advanced Caché interpreter. Can you give me a hint on what features do you think, please?

It should be very easy to implement something like a simple code completion with Caché Keywords to use in a notebook. But at this time I think all is limited to the JDBC interface, and with that to SQL.
Would be really great if we could use also COS to fetch data... !?

I think also like Michael that this is an issue related to the data.
Maybe you can delimit this beavior to the caused column by execute your SQL statement with only one column at a time to test the columns one by one.

"SELECT Name FROM ZenCrm.OAdress" -> works?

"SELECT Type FROM ZenCrm.OAdress" -> works?

and so on.

I use SQL Server quit a lot and I've never seen that you can connect via SSMS to any other databases than MS SQL Server... You can use the Linked Server Feature to use Caché via SQL Server and use the SSMS to query Caché. But this a overkill just to execute some queries I think.

Attention advertising ;-) : You can take a look at Caché Monitor to connect directly to Caché (and other DBs). If you are familiar with SSMS you find many identical UI concepts.



Hi Andy! The logical explanation for this behavior is that changing the select list causes the query optimizer to choose another execution plan\access path. Unfortunately the new plan is slower than the first one.

Like David describe I think the first step is to check that all tables has selectivity information. These infos are very important and used by the optimzer to find the "right"\fastest plan. You can evaluate this by compare the used plans.

So: -> execute TuneTable and check again.