Printed Icetips Article

To reduce code (and coding errors) a queue can be constructed so it actually defines part of a SELECT statement. For me, this a really cool thing.

In the demo app at http://www.icetips.com/downloadfile.php?FileID=59 , look at the BrowsePlayers procedure. Look at how the PlayerQueue queue is declared. It's like this:

PlayerQueue Queue
PlayerName   Like(pla:playername),Name('players.playername')
TeamName     Like(tea:teamname),  Name('teams.teamname')
Playerid     Like(pla:playerid),  Name('players.playerid')
TeamID       Like(tea:teamid),    Name('teams.teamid')
            End

Can you do that with the NAME attribute? You bet!

Now we have a queue that handles the results, can display in a list box, and assists in constructing some of your SELECT statement.

To use:

 Code
 QueryFromQueue(PlayerQueue, ' from teams,players ' &|
                             ' where players.teamid = |
                               teams.teamid')

A one liner! And absolutely no reference in any of that to any file structure at all!

(The QueryFromQueue procedure is in the demo app, so you can see how it works.)

If you have to change your queue structure, notice how your resulting sql is changed automatically.

I don't know about the rest of you, but this is very powerful in my opinion.

Note: You can use expressions in the NAME attribute of your queue structure, as well. The only restriction I've seen is when the contents of the name attribute is very very long, and the symptom will be a GPF when you enter any code in the module.

Probably no single item causes more discussion in Clarion programming than the browse. With a desktop file system, browses are hard enough, but at least they are fast. This is because of the SET, NEXT, NEXT processing which is very efficient with such files.