I should add that a LOT of the code is functionality that PG has built
in or the other languages available do.  String functions for instance
or chunks of code that flatten tables and cache query results for
efficiency looks like PG's caching stuff will make this unnecessarily).

On 3/13/2020 7:50 AM, Mark Bannister wrote:
> Yes, I'm seeing how good the functions will be.  Also looks like views
> will play a role.
> My app is BIG.  I figured it out the other day:
> "Now I just have to rework 270 forms, 195 reports, 805 tables, 40
> libraries (12M of .lsl files ) ...."
> 
> On 3/12/2020 11:22 PM, Tom Krieg wrote:
>>
>> I forgot to add this:
>>
>> Using pass-through SQL means the BDE just acts like a tunnel between the
>> form and the server. The BDE turns the results  of your sql into a table
>> or in-memory tcursor.
>>
>> Paradox Form/Library SQL --> BDE Tunnel --> ODBC --> Database
>>                                                        
|
>>             <-------------  Table/TC <------------------
>>
>> Virtually every one of my SQL commands in a Paradox app is
>>
>> SELECT * FROM "SomeFunctionName" (data, data, data, ... etc ... ,data);
>>
>> The functions do everything, update, extract, get some data, assign
>> record keys etc. Some functions return tables, others return multiple or
>> single values, others nothing at all (they either execute or they
>> don't). Paradox is only used for the UI. It's amazing how you can use
>> Paradox when you don't have the restrictions of the BDE.
>>
>> On 13/03/2020 12:21 pm, Tom Krieg wrote:
>>>
>>> Connecting directly is like
>>>
>>> Tcursor/Tableframe --> BDE --> SQL Commands --> ODBC --> PG Database
>>>
>