On 14 December 2016 at 12:52, (WalzCraft) Jerry Forss
<JForss@xxxxxxxxxxxxx> wrote:
Enter name (partial), setll and read 10 records loading SFL.
User can page back so does setLL again and does READP loading array then loads SFL again.
I want to make all this happen using SQL to modernize my skills.
The name is ONLY a starting point, not a match.
What you describe is probably the purest RPG idiom. The card
catalogue. We have a sorted list, the user sticks her finger into the
list starting... here... and she manually searches each card from that
point on to see if it's The One. SQL is more like asking the
librarian to pick out the 5 books that meet my criteria and letting me
choose among that small, filtered list.
Having wasted your time with a goofy analogy (at least it wasn't
cars), I'd like to advise you to resist the urge to swap SETLL out and
FETCH in. They aren't interchangeable. Leave the SETLL as-is, and
add the SQL as new functionality. What I did:
There's a block of code that clears the subfile. Make it a subroutine.
There's a block of code that loads the subfile. Make it a subr.
Add some 'filter' choices on the display.
If the user puts in the name in the regular place, load with the SETLL subr.
If she uses the new filter fields, load with the new SQL subr.
In that new subr, you can start off with static SQL like Booth's
example. The most important lesson I learnt at this stage was to
ALWAYS, ALWAYS, ALWAYS check SQLSTATE. Some prefer SQLCODE - that's
OK. Ignoring SQLSTATE/SQLCODE is exactly like ignoring the 'no record
found' indicator. Bad juju.
Once you get comfortable with the syntax of simple SQL you can try
some dynamic SQL. As Charles notes, dynamic SQL shouldn't be your 'go
to' answer for all SQL problems, but this 'search and filter' problem
can be a good place to try it out.
At the end of the day, by extending the user's reach into your
database, you will have given her new abilities, and by doing that
with SQL you will have given yourself some too.
--buck
midrange.com
