Am 11.08.2025 um 09:45 schrieb Patrik Schindler <poc@xxxxxxxxxx>:
Am 11.08.2025 um 08:22 schrieb Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx>:
Each SQL Statement has to run at least one time through a FULL OPEN (full optimization) which is very time consuming.
Yes, this matches my observation. Hence I try hard to avoid using SQL for interactive applications. The startup delay is unbearable. For batch jobs, the delay doesn't matter to me. I admit, this all is very specific to my situation.
If an interactive SQL driven application starts so much slower than a RLA driven application, something is wrong with the application design - not with SQL. Yes there is a small overhead with SQL - but even on a 170 it shouldn't be so much.
Maybe there is no usable Index, because the predicates and the order by don't match - maybe the SQL design is bad - like looping through an cursor and having additional SQL inside the loop to get more data (instead of getting everything together in one query) - there are many big and small mistakes that one can make, that will have a negative impact on performance.
If you like, just send me an example of an interactive SQL application that you think, is too slow - I can look at it, and see, where the problems might be.
Of course I understand, that you're a hobbyist - that's absolutely fine with me. But you should point that definitely out, if you give hints about CTL-OPTs or something like that, because it matters. And from my PoV - you should ALWAYS do things right - have a standard /COPY for CTL-OPTs and one for SQL options, use service programs for "business logic", use row-set-based SQL, and so on ...
Not because if gives you an immediate advantage, but because you never know, what will rise from that in the future, and because your thinking will be formed - or like some much smarter guys than we wrote: Care about your craft!
Having said that, I recommend that you get a copy of The Pragmatic Programmer (if you haven't read it already) - IMHO it's one of the best books about our craft (programming) and it teaches your to form "good habits" and get a better programmer - completely agnostic of the language you use - these tips are somehow universal truths of our trade.
HTH and kind regards,
Daniel
P.S.: Here is the link:
https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ ... and I don't get anything from that - it's just my go-to recommendation for everyone who programs - whether personal or professional.
midrange.com
