2 years ago
I've deployed a new mysql build.
I created a custom database with the name I wanted.
I then went to my project dashboard, clicked on my project, and selected the deployed mysql service.
From there I clicked on the Variables tab and modified the MYSQLDATABASE and MYSQL_DATABASE variables to point to my custom database name instead of the default railway.
Upon doing so, I was able to see the two tables that my custom database contains in the Data tab.
Clicking on the first table successfully brings up the table and shows the rows and associated data.
Clicking on the second table however, causes an error to appear.
Cannot read properties of undefined (reading 'Column_name')
Is there more that I need to change other than the two aforementioned variables I've changed in order to get the web-ui to work properly with my custom database name?
I noticed simply changing one of the variables only allowed me to see the table names but I had to change both variables in order to be able to actually click on and see the first table. I'm not really sure why the second table is not working.
16 Replies
2 years ago
From the sounds of it, it doesn't seem like you did anything wrong, I think the data tab just isn't compatible with whatever is in that table.
I'll report this to the applicable team member!
Would you mind also sending your project id please?
2 years ago
From the sounds of it, it doesn't seem like you did anything wrong, I think the data tab just isn't compatible with whatever is in that table.
I'll report this to the applicable team member!
Would you mind also sending your project id please?
Sure thing, thanks for the prompt response!
Project-ID: aebb3864-6d71-420d-aa23-30f0e4885e69
2 years ago
Messaged them, I'm sure you'll hear back from either me or the team member fp.
2 years ago
Messaged them, I'm sure you'll hear back from either me or the team member fp.
Perfect. Thank you again! :)
2 years ago
I think I just fixed it!
I believe my sql import was corrupted somehow as the primary key and indexes were not set. Upon fixing that it seems to be working as expected.
2 years ago
This still should be accounted for in the data tab, if you could replicate the issue in another database i'm sure the team would very much appreciate that.
If you enable your public profile i'll comp you the credits needed.
2 years ago
This still should be accounted for in the data tab, if you could replicate the issue in another database i'm sure the team would very much appreciate that.
If you enable your public profile i'll comp you the credits needed.
Okay, I'll enable my public profile now. :)
Should I deploy a new project for it or just create another database and re-import the corrupted sql file into there for the team to investigate?
2 years ago
Okay I've reproduced it on a new project. Here's the project id: a7dacd92-2fcf-4ced-a330-da9521eb0bf9
2 years ago
I've noticed something else:
One of my tables has a datetime_last_updated column.
The time that is shown on the Data tab through the web-ui is wrong (it's 1 hour ahead). When I verify the data through MySQL Workbench, the times are correct, so it seems to be a display issue on the web-ui end?
2 years ago
Perhaps the data ui is showing you the localized timestamp and it's saved as UTC in your database, or vice versa.
2 years ago
Does the table not have a primary key? The UI expects a primary key to exist and that's what is failing and causing the error. We should probably show a better error there irrespectively.
2 years ago
Does the table not have a primary key? The UI expects a primary key to exist and that's what is failing and causing the error. We should probably show a better error there irrespectively.
Yes, I believe that's what was causing the issue... I agree a more informative error message would probably be helpful there.
I think I just fixed it!
I believe my sql import was corrupted somehow as the primary key and indexes were not set. Upon fixing that it seems to be working as expected.
2 years ago
Perhaps the data ui is showing you the localized timestamp and it's saved as UTC in your database, or vice versa.
I'm not sure tbh. As it's only a display issue I'm not too bothered about it but thought I'd report it anyway.