Thank you for the suggestions!
My problem seemed to consist of at least two parts
1. There are characters in the files that LOAD DATA can not process
2. LOAD DATA is currently terminated with an error even in case of success.
I think it would be a helpful enhancement for the LOAD DATA feature if erroneous lines e.g. would be redirected to a textfile for later analysis.
Maybe an option for 2022.2 wink

I'll created a fork on github (https://github.com/andreas5588/zeppelin) 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 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.

Regards

Andreas

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.