> 3. It relies on paradox, which is exactly what we are avoiding.

duh !! :-)

but that means there will always be restrictions, for better or worse.. what 
if your converter finds a query and starts crunching it, and it doesn't know 
that it's totally invalid? most query errors are runtime errors, not syntax 
errors

--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Bernie van't Hof"  wrote in message 
news:5af5d60c$1@pnews.thedbcommunity.com...

Three problems:

1. I think paradox converter has limitations. I know it doesn't handle sets, 
and I believe there are other complexity
limits as well. I don't have later paradox, but if someone would test a 
couple of these (the ones with deletes or
changetos) that would be fantastic. If nothing else it would give some 
clues.

2. Your solution is completely static and must be done for each and every 
query. The goal here is to be completely
dynamic - reading in the query, converting to table query images, accepting 
modifications, then converting into SQL and
executing.

3. It relies on paradox, which is exactly what we are avoiding.

- Bernie

On 12/5/18 3:21 am, Steven Green wrote:
> Bernie.. paradox itself will create the SQL for any query.. maybe you can 
> find a way to extract the weird queries to text files and run them thru 
> paradox itself, as part of the conversion package
>
>
> -- 
>
> Steven Green
> Myrtle Beach, South Carolina, USA
>
> http://www.OasisTradingPost.com
>
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Bernie van't Hof"  wrote in message 
> news:5af5d01d@pnews.thedbcommunity.com...
>
> 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.
>
> 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
>>
>
> - Bernie