If I were you, I would export this worksheet as a csv and then use the "schema.ini" topic at the end of this article to pre-define what the data type of each column in your file is:
I'm not 100% sure you need to export as csv either, since the JET database engine is used to load both a csv / excel / access database file.
Schema.ini is always a great fallback. Are your %s in Excel really percents or text with a % symbol. The former should be fine, but you could try formatting as a number. If the latter you could strip the % out and divide by 100 to get back to a number.
EDIT: hadn't seen you had attached the file. Changing the format to number fixes this. When in Tableau, change the data type to number, then you can format it as a percent. The blanks in the first few rows are causing JET to label it as text.
Thanks bith Russel and Alex for your response. yes, it is %. I tried to strip out and left just the numbers but still could not get it to work.
when I view the data, it shows the numbers but on graphs still shows Abc
You need to drag both of the number columns down to measures. This should help you understand the difference:
Edit: replaced as original link (rightfully) was talking about discrete vs. continuous
I got the folowing response from support team and it worked. Thanks everyone.
Create a calculated field on each column that is coming in as a string because of the percentage sign as follows:
This will strip off the "%" and turn the string into a float. Use the calculated fields in the Viz instead of the string dimensions.
This is an old thread but I want to follow up and provide some fresh content. I encountered the same problem. I have a VARCHAR(X) type of field coming in as an integer and giving me NULL for each instance where the source file contains a non-numeric character.
I used the Schema.ini approach. This worked. The column names in the Schema.ini have to be exactly as in the source file. I am using a tab-delimited file.
Use the Jet data types.
I am using PL/SQL and saving my files as tab-delimited. In the Schema.ini, you might need to go into your source file and add a column for the row number that is being written out by PL/SQL. Seems reasonable that there is an option to suppress the row number in the output. I haven't checked yet. I'll be taking this to production so will need to resolve the issue of the row number with the intention of suppressing it. Because I'm going into production, Schema.ini is better than having to update the registry.
As a couple of final tips, be sure to save the Schema.ini in the same directory as the source file. Refresh the data and then inspect it. It took me about five iterations to get the schema right.