this is the situation. I've an old Deplhi7 application, working on Firebird 3.8, that interacts with a much older Delphi5 application based on BDE (!!!). Our customer wants to upgrade this app, because BDE has become somewhat unstable on Windows10/11, no to mention the inability to translate regular SQL statement of medium complexity.
My colleague had already developed a Net MAUI app for our customers, and it has been adapted to this specific customer's requests (as mainly it does the same basic work - order collect). Net MAUI was chosen because of its multi-platform nature, but the majority of our customer's portfolio use iPads.
The problem arose when I had to interface with that database on Windows machines and, consequently, the app had to be deployed on the Windows x64 platform. While on iOS and Android the datetime columns appear correct (we both use SqliteExpert for checking the data), on the Windows deployment the columns created as DATETIME
(I know Sqlite doesn't have a dedicated type for date/time values) are seen as 18 digits big integers.
My Delphi7 app (no plans to migrate it to a more modern platform) uses Zeos 8.0.0 library, and works fine with all sorts of queries involving datetime columns as long as I'm the one writing that data using Zeos DataSet.Fields[n].AsDatetime
function (and the Net MAUI read them back correctly). But when the Net MAUI app writes some data into the Datetime-defined columns they become strange 18 digits big integer value. Sqlite Expert shows them as 18 digit values but it's not able to show the corresponding date value.
This value can be converted in a classic Delphi DateTime value by subtracting to it the value 621355968000000000, dividing the result by 10000000 (the number of C# ticks per millisecond per the number of milliseconds in a second), and then converting it from Unix time.
The only workaround I've found so far is dealing with DateTime values converted through the DateTime-defined columns AsString
property, but I believe it's not a great way to deal with these values, and more prone to errors compared to the AsDateTime
approach.
Has anyone using this combination of platforms encountered such an issue?
Thanks.
Rodolfo.