I don’t have experience with that.
If you change:
row.Column("LogTimestamp").DateTimeValue = d
to
row.Column("LogTimestamp").StringValue = d.SQLDateTime
do you get anything different?
let me do a test now and I will come back with the feedback, I assume that if that is the case it should work, so do you think it is a XOJO issue ?
Well to update, it seems that the app is an WebApp and using StringValue I get exactly same issue .
I will try to see maybe I can print that on a log in the file to see If DateTime.Now shows same error or not As the date seems like it is stuck to that timestamp.
Thanks
Create a simple sample app replicating the issue. Let us see were the error is in our labs.
1 Like
Hello guys,
So I managed to do some tests and I took the simple SQLite project from examples SQLite (Desktop) one and I just added the DateTime column and added data.
The result is that data is stored properly and shows properly on XOJO app and based on the debugger but it shows wrong in SQLPro app so I opened a ticket there to see what could be the problem to see if something changed on XOJO side that shows like that or if they do have a bug that messes the data.
I’ll keep you updated .
Thanks
1 Like
Can you use SQLite directly to see what happens there?
Hi guys,
So the weird thing that I got from the developer, and apparently it worked.
He asked me to put the Display timestamps as : Epic date strings and now it works.
It seems that something is changing maybe on the DB side to adapt the locale I guess for more accurate data. Now, while the problem was fixed on their side, and I can see current data properly, I am wondering , knowing that epoch is somewhere in 1970, what happens if I have dates earlier than 1970 ? I can still use that epoch thing and see proper data ?
@AlbertoD it seems that using the SQLite example and putting the column to show the data it shows proper data.
Thanks
And he just confirmed that using that setting will show properly and it will properly process the data, so problem solved, for now, I hope
What option was before? Strange how SQLPro handle dates.
The blue one “Core data(localtime) strings”
1 Like
Oh, so it looks like SQLPro reads “2024-02-20 08:11:00” but expects “2024/02/20 08:11:00” and decide to show some default like “2001/01/01 00:33:44”. Weird.