I wasn't doubting the query works. We've all created some doozies in our time. It uses just
about every construct there 
is in a select type query! Might make a good test, even though we've got no idea what it is
trying to do!

I doubt you are the only one who used the many constructs in some form or another, and they
are all valid.

In the main I can see how to break them down into building blocks. My main concern is generation
of correct inserted, 
deleted and changed tables. And even that I can vaguely see a way through, it just gets that
bit more complicated.

I think a fair assumption is that a pdox query operates on the tables in their state at the
entry to the query e.g. if 
there are multiple changeto rows they will not affect each other.

I think you didn't try to change more than one table in a single query, which is a good thing.
Not sure pdox meant to 
allow that anyway.

As always the challenge is to discover the rules and codify them cleanly.

Thank you all for your invaluable support and input.

- Bernie

On 12/5/18 5:32 am, Michael Kennedy wrote:
> On 11/05/2018 18:17, Bernie van't Hof wrote:
>> Most of these are selects with various tests, which are not too hard to convert using
multiple queries and UNION.
>>
>> There are some that change or delete and that is giving me pause for thought. Maybe
the only way is multiple queries 
>> in a TRANSACTION, but that causes complications building the CHANGED and DELETED result
tables. Mmmmmmm.
> 
> Well, if I'm the only one running some of these oddball constructs then maybe skip them?
> 
>> Also a timely reminder to implement "!". I currently recognise it but don't follow
through in the join.
>>
>> And I bet you had fun with this one:
>>
>> On 11/5/18 8:02 am, Michael Kennedy wrote:
>>>     Menu {Ask} Select Trans_01_Tmp
>>>        Moveto [Account No]      "_ac"
>>>        Moveto [Year End Date]   "_dt"
>>>        Moveto [Run Batches]     "Y"
>>>        Moveto [Business Typ]    "~ForB"  ;Fishing/BUSINESS
>>>
>>>     MENU {Ask} SELECT TaxPadP
>>>        MOVETO [Account No]      "_a!,_ac"   CHECKPLUS
>>>        MOVETO [Year End Date]   "_b!,_dt"   CHECKPLUS
>>>        [Line No]              = "~tot_line"  ;= match on line
"37"
>>>     DOWN                                    
;A-N-D (because of next _a,_b)
>>>        MOVETO [Account No]      "_a"     ;??? Maybe ",count=0" here
also
>>>        MOVETO [Year End Date]   "_b"     ;??? Maybe ",count=0" here
also
>>>
>>>        [Line No]              = "not ~tot_line,count=0" ;have
a total of NO
>>>                                                        
;lines, WITHOUT 37
>>>     Do_It!  Qry_is_Ok("B18")   ClearAll
> 
> Wow - that looks like many wasted hours and lost sleep  ;-)
> 
> However, though I do vaguely recall the actual app, I've no clue now what all that "37"
thing is all about, and what the 
> query was trying to achieve. However, that app was run by a few hundred users, maybe 10-20-30
times per working day, 
> over, perhaps 25-30 years, and is probably still running, and I'm pretty sure the query
is working correctly  ;-)
> 
> If you want me to dig out the context, and exactly what it's trying to do, let me know.
> 
>    - Mike