Coinerc
commented
2 years ago One of my users discovered this issue for the first time this week. I placed it in our pivotal ticket system as a bug fix. The work around was to move a row with the proper formatting to the top row. Not convenient but a work around. The system should be looking at the datastore type to determine if an attribute is valid not looking at the top row of data being imported.
Recently we had an employee attempting to import all of 2020’s Spawning Ground Survey Redd data with an .xlsx file. In the dataset there is a “GPS Unit” field that is a string field both in the Fields table and in SSMS. For the most part those values are numeric, but it is a string to also allow values such as “NC” when a GPS is not used. In the imported .xlsx file, there were two “NC” values (at record number 5 and 6) in the GPS Unit column, all other values being integers.
After selecting the file for import and clicking the Load>> button, the importer displayed an error before reaching the column mapper when those two ‘NC’ records are not at the top of the .xlsx file.
It seems like the importer is assigning a datatype (double here) before you reach the column mapper. If I change the file to a CSV, this issue doesn’t happen (because all CSV fields are treated as text?). This also doesn’t happen if I rearrange the data to have the “NC” records on the top (.xslx import). My thoughts are the importer assumes the “GPS Unit” is a text/string field due to the “NC” values in the first position – which consequently will accept numeric values as strings. This won’t happen for a double column (“NC” records not arranged in first position), where a text string is not accepted – hence the error above.