Upgradability is another. If you have all your processing logic in 
functions (procedures) and triggers on the server, and only link to 
answer or result tables in Paradox, you can, heaven forbid, just link 
your database to (Groan) Visual Studio and rewrite the User UI in C#. Or 
Visual Basic (the easiest migration path for Opal programmers) or Visual 
Pascal (Delphi) if you're a masochist.

Then you can take your C# code and change it to a multi-platform app 
that'll run on iThings and Android.

Then, if your app is really good Google will either rip it off or offer 
you a couple of billion for it (depending on how many bear traps you've 
put in it).

On 12/03/2020 12:26 pm, Tom Krieg wrote:
> Another reason to always keep all the database processing and retrieving 
> logic on the PG server. Rather than link to a PG table in your form, do 
> a pass-through PG SELECT .... FROM <table> and link to the result table.
> 
> You're going to spend a lot of unfruitful time trying to get direct 
> linking working and when you finally separate Paradox and Postgres with 
> pass-through SQL that time will have been wasted. Grit your teeth and 
> separate the two now. You'll be glad you did. Performance for one.
> 
> On 12/03/2020 10:21 am, Mark Bannister wrote:
>> It looks likes pdox cannot use an index that has uses the lower function
>> in it.  You get a "number out of range" error and if you look at the
>> table in the filter dialog the index field names are missing on those
>> fields.
>>
>> -- 
>> Mark B
>>
>