Adding a screen (table block) for a particular postgreSQL table does not work as expected

[kpturner]

For all my tables (except one) if I create a screen and take the Quickly create a screen from your data option, I ended up with a functional table that lists all the rows which I can then start to augment to my needs. For example:

For one particular table, however, it does not do that. Instead of a table I get this:

I cannot see anything particularly unusual about this table. It just has a few fields and a primary key constraint (iso column) so what would cause this?

[kpturner]

It seems that the default column width (Auto) sets the width of the column to be the full width or the container for some reason. Why?

[kpturner]

Strangely, if I "Configure Columns" and add them all, then set the all to a width of 200px, it does at least render the table nicely. If I then reset them one by one back to "Auto" it remains fine.

Is this a bug?

[ConorWebb96]

Apologies, its the div with the class; spectrum-Table

[kpturner]

Well if I add a new table block component for this table without doing anything to configure the columns, they are again a mess and I see (invalid CSS). No idea where 200 comes from.

With the component I modified to make it work again with Auto I see

[kpturner]

If I manually change the widths from Auto to minmax(auto, 1fr) then it renders ok and I am back to

[kpturner]

On a different table if I add a table block component I also get

out of the box. So something in the country table is corrupted with regard to column widths. If I set it to Auto I do not end up with minmax(auto, 1fr), I end up with Auto. If I don't touch anything I end up with 200

[ConorWebb96]

Hey @kpturner,

Could I get the schema for the table that is being affected. Its very strange that its only affecting one of your tables and not the others. I'm assuming you are using the Postgres data source?

Does the issue still persist when you eject the table block component?

An app export would be great also so we can have your exact settings! Feel free to email it to [email protected] if you don't want to attach it here.

Thanks for the information!

[kpturner]

Bug report: #11051

[ConorWebb96]

Could you also provide a sample app export and schema for the table in the bug report, so we have an example to work from to fix!

Thank you!

[kpturner]

If I export the app, will it not contain also the password for the datasource? I cannot provide that. It begs the question, can you see that by looking at the hosted app?

[ConorWebb96]

You are right it will contain the passwords within the app export, the only way around this would be if you were business tier and used env variables.

As you are on the free tier. Could you provide the table's schema thats causing this to happen. So we can try and replicate, feel free to attach this onto the bug report you created! As it will be very helpful for us, it doesn't have to include any data.

Thanks again for raising this!

[andz-bb]

Hi @kpturner, thanks for sending us your db schema. I spent some time investigating your issue but unfortunately I have not been able to replicate it on my end.

I imported your schema into my local Postgres server and created a new app with that as the datasource. When I generated a screen for the empty country table, the table rendered properly and was formatted correctly.

I then configured the country-currency relationship in Budibase and added a test row to each table to make sure the data itself wasn't causing problems. When I deleted and regenerated the screen it still looked OK.

Does the issue still occur if you re-fetch the tables in your Postgres datasource settings and then regenerate the screen/table? Are you able to replicate it using the same db in a brand new app? Thanks

[kpturner]

I think I mentioned this elsewhere but re-importing the tables makes no difference. It seems that once BB has hold of the table and has populated its own internal DB with info about the table, it has you on toast. There is no facility to completely delete a table from BB either. Once it has been imported, it is impossible to get rid of it there is a separate discussion about that).

I will try another app later

[kpturner]

Update: There is no problem on a new app.

[andz-bb]

thanks for the quick response @kpturner

Just to double check, does it still hang on to that info when you delete your screens and the whole Postgres datasource and then re-add them?

[kpturner]

Deleting the datasource completely is rather inconvenient in that I lose all my changes and I am not sure what happens to the screens using that datasource. Nevertheless I deleted them all and the datasource and started again. That worked.

[kpturner]

I have just had this happen again with another table. This time the table was all fine (screens deigned and save - all OK).
I then wanted to check the type of one particular field. So I went to visit the grid in the Data section (as opposed to Design) edited one of the columns to ensure it was Number, clicked save and the returned to the design. This was the result for the table page:

Deleting and reimporting the schema is not an option now.