Re: main difference between expandable and singlepage subfile

Hell,

Am 30.12.2019 um 20:56 schrieb Booth Martin <booth@xxxxxxxxxxxx>:

Why do a position-to when sql offers "like" so you can easily use wildcard filters to provide human-scale load-all subfiles, even with huge files?

Because to me, the embedded SQL in RPG is even more cumbersome. :-) Also, on my 150, SQL is (obviously) slow. And last, to utilize LIKE, I need to tinker around with SQLDS. I didn't have the nerves to do that yet. :-)

SQL is nice on fast platforms and with proper integration into programming languages. I'm using SQL within Perl on Linux with the DBI interface with great joy and success. What IBM delivered with their SQL-precompiler-link-binary-blob-stuff is just awful and I try to omit it where possible. I don't know if this has changed significantly in later releases, though.

Specifically _because_ underlying PF data may change you, as the designer, can build in frequent refreshes so that users don't page around in hours-old data.

I can't see how that is supposed to save CPU cycles (aka: resources) compared to "old" API calls and frequent refreshes.

Load-all subfile programs are around 200 lines of code, easy to reuse.

I also have some of those, where it's obvious that the amount of records will not exceed some dozen. Not much scrolling and it's not too cumbersome to locate a certain record "by hand".

(I have a 2-column load-all subfile program with 235 lines. It includes wildcard filtering on either or both columns, and either column may be sorted in ascending or descending order. 235 lines including headings and comments.

Interesting. Using SQL, I assume? How do you handle record locking when loading a record for editing into a "details-screen"? Or do you count that part outside of your load-all? If you do, essentially stuffing a loop in 235 lines isn't too hard, I assume. ;-)

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc