|Subject:||Re: Postgresql connection
|Date:||Tue, 5 Feb 2019 12:46:09 +1100
|From:||Tom Krieg <REMOVEtomkCAPITALS@sdassociates.com.au>
You need to change the way you think when you use any SQL database.
First, I would use sequences and an integer field for keys, rather than
a serial field. I have a stored procedure that allocates keys, based on
a built-in sequence but it also optionally adds suffixes, prefixes and
in some cases for particular tables it generates a Microsoft GUID.
Secondly, the data in your priv (and on your form) is not connected to
the database. The only connection should be
You send data to the database - the database processes the data
You request data from the database - the database sends it to priv.
If you want to update the display, you need to re-request the data from
the database. On some forms, like a day-planner for schedulers, I had a
timer which would do a query and refresh the screen automatically.
That's also why I pushed record updates from a tableframe to the
database on postrecord. First I'd try the db update, if it worked I'd do
the post and unlockrecord, if not I'd undo the changes on the TF. But
you could set a change flag and do the update all at once. In that case,
you need record versions on the database. Include the version when you
extract the data then, when you update, check the version first.
Remember, when you lock a record on the screen, the database record
isn't locked as well. It can be changed by someone else. Then we have
transactions, clean reads, dirty reads and all the reads in between.
Hehehehehe. You'll get to those. They are immensely useful and powerful.
Mark Bannister wrote on 5/02/2019 9:12 AM:
> Also, I'm playing with PostgreSQL 11 and using the serial datatype for
> key fields. Interactively on a form pdox will not update the display of
> the key field if a new records is inserted. Actually it does on the
> first insert but not subsequent ones. I have to close and open the form
> to see the new records.
> If I use a Tcursor I must enter data into some other field and unlock to
> get the key field to be updated. I see your stored procedure call in
> your sample library. was it an attempt to get around this?
> The forceRefresh() call does not seem to do anything.