Query regarding import of CSV rows into exiting glide table for Free plan

Ask for Help
1

Hi all… Is there a limit on how many rows can be imported into an existing Glide table from a CSV on the free plan? Such as only able to do 50 rows at a time? Or am I going crazy and obviously doing something wrong?

I’m right clicking on the glide table I want to import into and then selecting the CSV file and then clicking Continue and it does a quick little wavy bar thingy but nothing ever imports! I’ve refreshed, exited out and back in but data never seems to import.

What am I missing?

Thanks…

1 Like
2

ok the issue seems to have been using csv. When I said save the spreadsheet as Excel and then tried it, it worked. Weird as it was a table downloaded from Glide… but at least it is working.

1 Like
3

Did it include RowIDs?
If you try and import data that contains RowID values back into the same Glide table, it will fail silently.

4

Ahh. Yeah it had row ID in both the CSV and the XLS (excel) file. I wanted to keep row ID as that’s how my tables link.

1 Like
5

I’m surprised that it worked when you used an Excel file. After the import, were the RowID values all the same?

1 Like
6

I’m not in front of pc but I will have a look see and let you know.

1 Like
7

So given the issue with a row I’d should we not use Row ID to link tables?

1 Like
8

It’s generally considered good practice to use RowIDs to link tables. But if you plan to do lots of exporting and importing of data then you just need to be aware of the behaviour I mentioned above.

What happens is when you delete rows from a regular Glide table, in the backend they are just marked as deleted, without actually being fully deleted. If you then try and import data into that table with the same RowID values as the rows you have deleted, the importer will detect them as duplicates and ignore them (ie. silent failure). This limitation only applies to regular Glide tables. With Big Tables you can export/import with the same RowID values and it will work fine.

2 Likes
9

Ok. And there is no trick to get around the issue when using regular Glide tables?

1 Like
10

Bugger, the Row IDs are different. This is going to throw out all the linking between the tables, isn’t it. How can I remedy this? I’m trying to move data from an old version of the Glide app to a newer version of the Glide app.

1 Like
11

There is, but it’s a bit cumbersome. You can do it as follows:

  • Export the data, then delete all the rows you just exported
  • Duplicate the App, choosing to duplicate the tables
  • Import the data into your duplicated copy. This will work, because those RowID values have never existed in this copy of the App.
1 Like
12

Well, essentially this is kind of what I’ve already done I think if I understand you.

Basically I duplicated the old app including tables. Then I deleted most of the rows in the tables and turned the data that was there to “dummy” data. Then I worked and updated the new version of the app while everyone was still using the old app.

So now what I foolishly thought I could do was clone the new app (incase I blew things up), delete the dummy data and then export data from the old app and then import into the new app… but that is where I ran into trouble…

I’m thinking my only option now is to change BOTH old and new versions of the apps to have NEW Row ID of my own creating and have all the tables link using the new Row ID instead of the Glide Row ID… Is that my only option?

1 Like
13

What you should have done is deleted the data before you duplicated the App.

1 Like
14

Potentially the Row IDs are still there as I still have the copy of the new app in case I blew things up. But I see this as a potential big head ache so I’m thinking I’m best to bite the bullet now and work out all the table linkings using Glide Row ID and change them all to a new unique Row ID that I make so that should I ever need to do this again Glide wont have a hiccup at the Row ID issue.

1 Like
15

If this is something you won’t do very often, then I’d recommend that you stick with RowIDs. It’s a lot easier than the extra overhead that comes with managing your own UUIDs.

As long as you follow the procedure I outlined on the odd occasion that you do need to duplicate the App, you should be fine.

I have to do this for one of my clients on a regular basis, and I always follow that procedure and never have a problem.

1 Like
16

Ok… I’ll see if I can save it still from the copy of the latest version of the app I took… Thanks for the info as always :grinning_cat:

1 Like
17

Just to clarify:

I wont need to export the data from the new app as it is dummy data… so do I just delete it? Then duplicate it and pick duplicate the tables. Then import the data from the old app?

1 Like
18

Yes :+1:

1 Like
19

OMG OMG OMG THAT WORKED!

Thank you! Thank you!

I have other tables I need to do as well so I’m not actually going to try any futher tonight as its late and I’m tired and that is recipe for disaster so in the morning I will repeat what I just did but do it for all the tables…

Finger and toes crossed!!!

2 Likes
20

Hi Darren. Can I ask one other question kind of in relation to this. Is there any way to copy a screen from the old app to the new app (within the free plan). I assume not but though I would ask before I start recreating it manually in the new app. Thanks

1 Like