We have been using the READ API to read data from Glide Table and it has been working fine for a very long time.
Today we are seeing an issue with 1 of the rows. (nothing has changed for months)
sW7po is a date column in Glide and for this particular row it is EMPTY, however the API is returning this number back which seems to an EPOC formated time stamp, but in Glide it is empty.
just above it you have jPRmf which is also a date column, and normally the value of the column is returned as a string, as in this one
We are seeing this in two columns, both dates, and both are empty in this row, other date columns in this same row that are blank are fine and other rows where the sW7po column is blank are also fine. Its just this row and 2 columns.
Any ideas or if Glide Support want to investigate, let me know. Otherwise, I will try to manually insert a date and override it and see if that clears it up.
If you try to edit the value in that cell, do you see anything?
No. Just the blinking cursor at the start, so no hidden characters
OK. Definitely looks like an epoch time which translates to March 17th 2024 at 4:19PM GMT. Do you have any other rows with a similar date and time, or at least with a minute if 19?
My only thought is that something is happening on Glide’s side where it maybe holds on to a previous row’s date when the current row date is empty. Something not getting cleared out.
Seems to be worth leaving it alone and submitting a ticket in my opinion. Or maybe create a new row with empty dates and see if you can easily reproduce the issue.
yes correct, if you look at the first screenshot I have jPRmf which has a time stamp, for 4:19:13, there is a few miliseconds difference.
I have many other rows before and after this where it is not an issue, and new ones being created every 5mins.
The strange thing is that its not just a caching issue, jPRmf is a string, this seems like some other object, but it does define it as time as you have the txOffset in there and kind is glide-date-time
I’ll open a ticket to see if they want to look at it, but it is breaking my script and stopping it from processing anything further.
Yeah that is definitely odd. Definitely seems like a bug to me.
It’s nice to leave the issue for support to inspect, but understandable if you it’s holding up production.
Is there any chance you can duplicate the app and data and see it the duplicate still has the issue? Then you could try to get the original app working again and glide can look at the duplicate. I realize that’s a bit to ask, but just throwing out ideas to make it easier for glide.
Maybe they will respond quickly if you submit a ticket…
I raised a ticket.
I can’t duplicate, its a legacy app (in plan to migrate anyway), but think this bug/issue is at the Glide Table level and I am assuming that the underlying Glide Table engine is same for the new and old, if not then probably not worth investigating too deeply ?
1 Like
