Relations pull data in random order instead of sheet order

So I ran into something odd. I’m building an app that is using . To build the chart I have a relation to link to the data, and then I’m using a Joined List column to get a comma delimited list to build the url for the chart image in a template column. Everything works well as far as building the chart, but one thing I noticed is that the relation pulls data in what appears to be a random order. Since we cannot specify an order on a relation, I would have expected it to at least follow sheet order. If you look at the chart below, the data was entered sequentially by date, so the data in the sheet (glide table) goes from earliest date time to latest date time, but due to the relation, the dates are all mixed up in a random order as shown in the chart below.

This is even being reflected in the single value column. The last row in my glide table has a date of December 12th, but if I create a single value column to get the value in the date column from the Last row in the relation, I get one of the rows that happens to have December 11th as the date, which is not the last row in the related data.

Has anybody else come across something similar? I have not tried in when referencing a google sheet, but I am seeing it in a glide table.


I did use Quickchart in one of my apps with Sheets and it worked well. Probably it’s a Glide Tables bug.


@Mark @George_B Is this anything you would want to look at? I have a relation (rel-GasLog and currently rel-GasLogLast10 as well) in my User Profile sheet that is getting matching rows from the Gas Log sheet based on Vehicle ID. For some reason the relation is not pulling back the records in the same order they were added to the Gas Log sheet. Based on the chart above (which is built off of data in the order it was pulled from the relation) you can see that the last 7 rows are always the last 7 rows pulled in from the relation. Whenever I add new rows, they always pull in through the relation before these same 7 rows. If you are familiar with DB2 databases, it acts like the relative record number (RRN) for these 7 rows are much greater than any other row added. This also causes issues when applying a Single Value (Last item) to the relation. The single value does not get the true last row, but instead pulls the 12/11 row every single time. Even if I add new rows to the end of the table with a newer date. This is the part that concerns me the most as it may affect other users that rely on the the Single Value getting the true last row as represented by the data in the data editor, and not a some random row.

I think I could delete these 7 problem rows and the app would work as expected, but I wanted to leave it intact for you to see if there happened to be a bug. I’m in no rush, so you can take a look whenever you have time.

This is also presenting itself as a problem when getting the 10th record from the end as a Single Value (sv-DatePrior10) in the Gas Log sheet that uses a self relation (rel-Self).

It’s acting like the Gas Log sheet has a weird sort order that different from what’s visible in the data editor.

You can preview as Jeff Mobile and select GMC as the vehicle.
Keep in mind that these issues are all within the data editor and with Glide Tables. This is not related to any lists or components that would otherwise allow me to specify a sort order.

P.S. In addition to my Conditional Relations request, being able to sort a relation within the Glide data editor would be beneficial in this case like this. Right now I have to rely on user entering data sequentially, but if they ever retroactively created rows, then it would throw things out of whack.


Hey there @Jeff_Hager, Happy Holidays.

Rows in Glide Tables should be ordered the same as Google Sheets, so the last row appended would be the last in the order returned by the relation. Please create a Support case by emailing so I can work it through the escalation process and get an engineer to take a look behind the scenes to see what is going on.



This will be fixed by Wednesday. Thank you for reporting!