Hello Sieghard. >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.
Sorry but I did not note those new versions of MSEclock, PostgresSQL and mailing list I just went to your site and indeed there are new update for 2023. I will transfert it to mseuniverse demo. But, appart to me, did you give the address of your site ? I think you prefer not to make your site "public" so is difficult to follow your updates. I understand that you dont want to be a Github user but it would be much easir for everybody if you share your demo there. About your new demo of PostgresSQL, I have to install all the dependence for database server, I hope it will be more out-of-the-box than FireBird. Fre;D ________________________________ De : Sieghard via mseide-msegui-talk <mseide-msegui-talk@lists.sourceforge.net> Envoyé : vendredi 1 septembre 2023 23:24 À : mseide-msegui-talk@lists.sourceforge.net <mseide-msegui-talk@lists.sourceforge.net> Cc : Sieghard <s_c_...@arcor.de> 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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
_______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
