Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Fred vS <fi...@ho...>]

Re-hello Sieghard.
About your problem with floating point formats, I need to jump into database-postgress, I will do asap.

But it seems that the project mOMot2. that uses fpc, is very complete and they have some "workaround" for missing fpc things.
When I am a few more "aware" about database, I will ask them (and also if they are interessed to help for a msegui-mORMot package).
https://github.com/synopse/mORMot2

Of course, I would be good too to ask it to fpc forum (but I dont have the courage for that 🙁 )

Fre;D

________________________________
De : Sieghard via mseide-msegui-talk <mse...@li...>
Envoyé : vendredi 1 septembre 2023 23:24
À : mse...@li... <mse...@li...>
Cc : Sieghard <s_...@ar...>
Objet : [MSEide-MSEgui-talk] Mailing list & mseide-db woes

Hello people here,

I'm already some time now in doubt about my ability to reach the mseide-
msegui mailing list. I wrote a few messages lately, and they all seemed to
appear correctly on the list, but I didn't get any sign they were seen by
anyone else. Although this might be because my messages weren't of interest
to somebody, I had expected that at least the announcement of a new version
of my "MSEclock" demo and an experimental PostgreSQL "browser" might have
been recognized.
So the question for me is: is the list dead, my access cut off, or can my
messages still be read by the participants?

In addition, I do have a problem I need help with.
It pertains to the above mentioned PostgreSQL "browser", that works quite
nicely for displaying the contents of a table, but which fails miserably
for updates, at least when a floating point field is involved. I suspect
this to arise from the way fpc (and msegui along with it) passes these
fields to an application.
PostgreSQL provides two distinct floating point formats (and quite a
number of data types not supported by the fpc functions at all), "double
precision", 64 bits wide, like fpc's "double"s, and "real", 32 bits wide,
corresponding to fpc's "single" type. But fpc maps both of them to doubles,
which might produce inconsistencies, perhaps even field corruption, for
automatic updates (i.e. updates without an explicitly constructed SQL
statement).
Sadly, there seems to be no way to even get notice of the correct field
size, and no method to inform the update process of it. This seems to let
_every_ update attempt of a real field fail, even "double precision" ones,
and subsequently, nothing seems to be updateable any more.
Above that, I've not (yet?) found any way to get access to the affected
record field's data, since the database functions of msegui are nearly
exclusively column (field) oriented. The only place I found access to a
record number at was in the SQLquery object, and this didn't seem to be
very reliable.
I'm stuck and deadlocked on the issue now and would appreciate any help
to continue and make this project into something really useful, and not
just for PostgreSQL but finally also for all the other database systems
msegui supports...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------




_______________________________________________
mseide-msegui-talk mailing list
mse...@li...
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk