I have a query in Excel, retrieving data from a different workbook. Recently, however, the table the query writes data to has failed with the error DataFormat.Error: Invalid cell value '#N/A'..
Going through the steps of the query in the query editor, it looks like the error happens when some rows used to be sorted out:
I suspect the error is because of a change of some column header in the source file, but I am far from certain if this is actually the case.
Is there any way to track down a more detailed error description, e.g. to get to know what cells it is that has the invalid values? Is there some other way to get a better grip on what is causing the error?
Power Query really doesn't seem to know what to do when it finds an excel error code (#N/A; #REF; etc). Often when working in Power query, there isn't a problem because the row containing the error code isn't actually loaded into the preview data. It isn't until you do an operation like sort, group, remove duplicates, or something that has to read through all the rows in the data set that you run into the problem.
You have to either fix this by using the try functionality in M to handle the error, or fix your source data so that it no longer contains the error code.
If you are sourcing from an Excel Spreadsheet, just after you import the data, before you even Promote Headers or Change Data types select all columns and delete errors.
That worked for me.
I overcame this error by inserting a "Remove Errors" step before Filtering.
if your source is an excel, search for the N/A inside of your workbook for values and replace them with proper values. then it should work.
Related
I'm trying to export data to my Access database from MS Excel using VBA.
Everything uploads fine except for two columns (ACT_FORBRNCE_DESC & ACT_FORBRNCE_STATUS_DESC) which both error out due to Type Conversion Failure. I know this is due to the first 25 rows being BLANK and later on in the file, there are non-BLANKs. I've tried to convert the column to TEXT format but it still errors out.
I can't seem to find a solution to this online - does anyone have any ideas?
FYI using dummy data is not a viable solution here in this instance.
Using the following as my Excel source
I then used the following in Access
SELECT Nz(FieldWithBlanks,"") AS Expr1, XL1.Field1, XL1.Field2 into newtable FROM [Excel 12.0;HDR=Yes; Database=C:\Databases\SO123.xlsx].[Sheet1$a1:c6] AS XL1;
Which gave the following
In the current Project i Need to Keep a Excel File which gets Values from a Machine to the Access Database to work with them and Import them in the Data Model.
Problem is some of the Values give invalid results due to the way they are saved. For example the timestamp is saved like
030420 instead of 03:04:20 and Access cant handle that and gives me a #NUMBER
I can not simply Change the datatype in Excel because the whole Excel gets refreshed every hour by a source that i cant influence.
Any help appreciated.
If Erik's proposal does not work, you can
- create a backup copy of your Excel source
- tweak the file: enter text in the first row of the problematic columns
- link the tweaked file into Access
- put back the real file in place.
Now the problematic columns should be read as Text, and you can build a query that solves any issue like conversion, null handling...
Link, don't import, the Excel file, and you have a linked table.
Now, use this linked table as source in a simpel select query where you modify the data and alias the fields as needed. For example:
Select
F1 As SomeName,
F2 As OtherName,
TimeSerial(Mid([F5],1,2),Mid([F5],3,2),Mid([F5],5,2)) As TrueTime
From
LinkedTable
Where
F7 Is Not Null
The use this query for your import.
Consider querying the Excel file instead of using a linked table.
The query can directly query an Excel range:
SELECT * FROM
[Excel 12.0 XML;DATABASE=PathToMyExcel;HDR=Yes;IMEX=1].[MyRange] t
Then, you can use functions like TimeSerial to cast numbers to time values.
I couldn't find this issue elsewhere on stackoverflow, so here goes: I am loading a table (named DataEntry3, approx 10K rows and 30 columns) from the same workbook into Power Query, but it is throwing the following error message:
[Expression.Error] An error occurred while accessing table DataEntry3 because it contains overflow errors. Please fix the errors and try again.
I'm confused since this is a fairly routine operation. Any ideas as to what might be going on?
Do you have any large numbers in your dataset? This can occur if a large number is mistakenly formatted as a date in Excel. I would check if giving a stronger type (Text or Number) to the columns resolves this issue.
Coming late but might help someone else.
Had this same problem and discovered that the Source location for the file was wrong (internal network changes and drive names changed)
Fixing this fixed the problem.
In my case it was a formatting issue. I used format painter for the new lines that were added to my source table and that fixed the problem.
I have a data flow task set up in SSIS.
The source is from an Excel source not an SQL DB.
The problem i seem to get is that, the package is importing empty rows.
My data has data in 555200 rows, but however when importing the SSIS package imports over 900,000 rows. The extra rows are imported even though the other empty.
When i then download this table into excel there are empty rows in between the data.
Is there anyway i can avoid this?
Thanks
Gerard
The best thing to do. If you can, is export the data to a flat file, csv or tab, and then read it in. The problem is even though those rows are blank they are not really empty. So when you hop across that ODBC-Excel bridge you are getting those rows as blanks.
You could possibly adjust the way the spreadsheet is generated to eliminate this problem or manually the delete the rows. The problem with these solutions is that they are not scalable or maintainable over the long term. You will also be stuck with that rickety ODBC bridge. The best long term solution is to avoid using the ODBC-Excel bridge entirely. By dumping the data to a flat file you have total control over how to read, validate, and interpret the data. You will not be at the mercy of a translation layer that is to this day riddled with bugs and is at the best of times "quirky"
You can also add in a Conditional Split component in your Data flow task, between the source task and the destination task. In here, check if somecolumn is null or empty - something that is consistent - meaning for every valid row, it has some data, and for every invalid row it's empty or null.
Then discard the output for that condition, sending the rest of the rows to the destination. You should then only get the amount of rows with valid data from Excel.
I'm trying to import an excel file in to a SQL Server 2000 database using DTS. This is nothing fancy, just a straight import. Where I work, we do this 1000 times a day. This procedure usually works without an issue but something must have changed in the file.
I'm getting the below error:
Screen shot of Error http://www.understandingguitar.org/wp-content/uploads/2008/12/packageerror-screenshot-20081212.jpg
I've checked to ensure that the column "AssignmentID" is stored as "text" in the excel sheet. I've also tried to change it to general. Exact same error regardless of setting. The field does contain numbers... I appreciate everyone's help on this!
Regards, Frank
Try opening at the excel file and see the column content.
Is any of the row value in that column right-aligned? (generally for numbers)?
I am guessing that such a row could be a problem.
It may be obvious, but is the destination string long enough to hold the string representation of the float? I'm not sure if Excel is rounding what it displays to you, so it may be worth trying with a wider column.
The answer has something to do with the fact that the procedure is expecting text but even if you set the properties (in the format dialog) to "text", excel may not handle the data as text. And hence, SQL Server (or the libraries) won't handle it to text.
When the procedures try to import it, the system feels that it is converting from a number to text and it expect that data maybe lost (even though no data will be lost) and the error is raised.
If figured out that I can get around this error by placing a ' (apostrophe) before each listed number. [I.E. '124321] This force excel to treat the number as text.
Hopefully this will save others the headache I now have from this. :-)
Regards,Frank