Hi all.
I’m refactoring a few tables and have run into an odd problem during the data import.
I exported a view from a very wide table. Then I created a new table to hold a subset of the original data. Finally, I tried to import the data into the new table.
Here’s the error I get:
All of the columns are lined up. The field types are compatible. (I think..) I don’t know where to go from here.
Mike
Hello,
I’m having similar issues.
I’ve successfully imported several databases into Excel without any problems.
But now, for some reason, it’s suddenly not working anymore.
The fields are created based on the descriptions, but no data is imported.
It doesn’t matter whether it’s Excel or CSV, self-hosted or in the cloud.
What’s striking is that when the fields are created automatically, field types other than the standard text field are suddenly assigned (which also don’t match the field’s content)—this hasn’t happened before.
If I reduce the number of fields to be imported, the import sometimes works. However, I can’t identify any specific field that might be causing the issue (especially since there are no unusual field types).
It seems to me that a really nasty bug snuck in with the latest NoCDB update. I would expect to see some information and feedback in the forum, even though there’s hardly any activity there.
Regards, Ulrich
@Ulrich - thanks for reporting this. field type auto-detection was un-intentionally enabled by default. we will rectify in our next release.
@Thud1415 can you share a sample file & steps to reproduce your issue?
Sorry for the delay in replying; I was out of town for a few days.
The original issue was that I had a wide table that I wanted to scale down to a few smaller tables. So, I created a view from the wide table and created a smaller table with the fields I wanted to extract. The plan was to extract the view into a csv file and then import it into the smaller table… after lining up all of the fields.
Since this didn’t work, as indicated earlier, I renamed the new table and just imported the csv file directly. This worked.
But, because I like NoCoDb so much, I reported my difficulty. If you still want the 2 files, I’d want to sanitize the csv file first.
Let me know.
Mike.
Hello, thanks for the initiative.
We suspect the issue may have been caused by the automatic type detection feature, which has been disabled in the latest version. However, we currently have no way to confirm whether that was the actual cause or if it was related to a different issue.
If you’d like to verify this, please try again using the latest version. If the problem still persists, we would appreciate it if you could share the reproducible steps along with the CSV file so we can investigate further.
Well, I attempted to pull down the latest container only to discover that I was already running the latest:
# docker pull nocodb/nocodb:latest
latest: Pulling from nocodb/nocodb
Digest: sha256:a0345c5824c05a005b2cc98282fc857510e24a0d968be35740218a839251379a
Status: Image is up to date for nocodb/nocodb:latest
So, I made sure that I could (still?) reproduce the error, and I can. What is the best way to get the files to you?
Mike.
Send it to cs at nocodb.com with the above link please
Done.
Hope that helps.
Mike
