Some of my queries get real weird to test various features and combinations.
The difficulty is not the parser - that's relatively easy - its the conversion to SQL.

To take this a bit further, would any of the following rules be too limiting?

Insert: In single table, single row only

Delete: In single table, single row only (if too hard to allow multi-row)

Changeto: In single table, single row only

Check etc: Multiple tables, multiple rows OK.
There are various degrees of difficulty depending on the pattern of specs and conditions
If different specs, eg calcs, then split into multiple selects and UNION. Simple column checks
can be unified and the 
conditions OR'd, not requiring a union.

Of course in each of the above there can be multiple linked tables and within a table there
can be action row(s) per 
above as well as condition row(s).

- Bernie

On 9/5/18 8:54 am, Larry DiGiovanni wrote:
> Bernie van't Hof wrote:
> 
>> But how far do I take this?
> 
> I looked at your first example and thought, "not that far."  I looked at your second example
and thought, "farther than 
> that."
> 
> Then I looked again at your first example and decided, "Yeah."  Except the unnatural-looking
joins.  Phew!
> 
>> What level of complexity is acceptable/common etc?
> 
> There are certain things you can only do with multi-line QBE.  For this sort of thing,
I'd say let your confidence level 
> dictate - as soon as you can imagine conditions getting misinterpreted in the parser, stop
there, and go back one step.
> 
> -- 
> Larry DiGiovanni
>