Thanks for the code!  Makes sense.
So when do you generate your key field numbers?  Is that liLineNo in the
code below?  I realize that you have a sql built in procedure that
generates them.

Looking through all that has to happen to change it might not be all
that bad (except all the form datamodels).  I use a custom method
TCattach every time I open a tcursor so that can be switched over easily.
Just had a thought about forms and reports.  I can make a new alias that
points to PRIV.  As long as the name is the same number of characters as
the old alias I can replace the old alias in forms and reports with the
new one and it won't corrupt the forms (ex., old: "MANAGER", new:
"PRIV567").  I use this trick to open multiple copies of the same form
now when pointing to PRIV data.  That solves manually fixing all those
forms. (side rant: pdox has almost always had the ability to replace any
table in the datamodel when the form is opened but this was never
exposed to the developer.)
Most of my queries I've been switching over to SQL over the years already.

On 2/25/2020 7:50 PM, Tom Krieg wrote:
> Yes. I did it by trapping datapost/dataunlock record in the tableframe.
> Then call a library method (passing the record data) which did the SQL
> thing and returned true or false. Then I would raise an error condition
> in Paradox and fail the tableframe update if the sql didn't work. This
> way, the TF was always in sync with the database.
> 
> The beauty of it is that you can create a whole series of inserts and
> updates in one transaction from a tableframe update. And roll them back
> if necessary.
> 
> Everything should be done with pass-through sql. With forms and
> libraries triggering the updates, inserts, deletes etc. These are then
> protected by PostgreSQL transactions so there is no need to worry about
> integrity of data.
> 
> And yes, you could have wireless workstations. Last system I did they
> had techs on the road with laptops and a 4G dongle. "Can I sign you up
> for $2mill worth of extrusions? Great. I've just put  through your order."
> 
> Of course, if you use Azure and Citrix you could put everything in the
> cloud, including Paradox.
> 
> For example:
> method action(var eventInfo ActionEvent)
> var
>    stError string
>    dynResponse dyAny
>    siStatus smallint
> endvar
> if eventInfo.id() = DataPostRecord
> or eventInfo.id() = DataUnlockRecord then
>    if ORDLINES.RecordStatus("New") = True then
>       liLineNo = liLineNo + 1
>       dmPut("ORDLINES","ORDER_NUMBER",liOrderNo)
>       dmPut("ORDLINES","ORDER_LINE",liLineNo)
>       dmPut("ORDLINES","QUANTITY_RECEIVED",0.00)
>    endif
>    if SaveOrderLine(siStatus,stError) then
>       LINE_STATUS.value = siStatus
>    else
>       eventInfo.setErrorCode(UserError)
>       msgStop("Could not save order line",stError)
>      if ORDLINES.RecordStatus("New") = True then
>         liLineNo = liLineNo - 1
>      endif
>      ORDLINES.PostAction(DataCancelRecord)
>      EXTERNAL_NUMBER.MoveTo()
>      return
>    endif
> endif
> if eventInfo.id() = DataDeleteRecord then
>    disableDefault
>    self.PostAction(DataCancelLine)
> endif
> if eventInfo.id() = DataCancelLine then
>    CancelOrderLine()
> endif
> 
> SaveOrderLine and CancelOrderLine are custom methods that do the SQL stuff.
> 
> On 26/02/2020 9:18 am, Mark Bannister wrote:
>> Thanks.  Trying to get my head around this....
>> So I've copied data to priv that is now a Paradox table.  Made changes.
>>   How do I insert back into the Postgresql table?  I keep getting an
>> saying the table in the PRIV directory does not exist:
>> 'Relations ":PRIV:tablename.db" does not exist'
>>
>> So for editing data do I have to build an insert query and NOT update
>> from the PRIV table?
>> ex:
>> INSERT INTO films (code, title, did, date_prod, kind) VALUES
>>      ('B6717', 'Tampopo', 110, '1985-02-10', 'Comedy'),
>>      ('HG120', 'The Dinner Game', 140, DEFAULT, 'Comedy');
>>
>>