I had a script working about a month ago and nothing has changed since. However, when I run the script now, it throws an error. The function I am trying to use is the Remove Duplicates function.
I've tried changing the function in multiple ways thinking that it may be the order, however, I cannot work out how it has broken since nothing has changed since it last worked.
ActiveSheet.Range("$A$1:$F$8000").RemoveDuplicates 1, xlYes
As stated, the expected result is that it removes all the duplicates at the end since the previous part of the script is removing a wide criteria.
Error message:
Data example and the highlight of what should be removed:
Test example which also failed on me which was a lot smaller:
EDIT
Found the issue now... the data was in a separate table within excel so I just copied it out and pasted it as values in a separate sheet.
I've added an edit to the question, however I'll post it here to close the question. The table was imported to excel as an XML and had stayed in that format, hence the function wasn't working properly. To fix it, all I had to do was copy all the data and paste it into a separate sheet as values.
Related
I have Excel 2010. A couple of months ago I wrote some UDF's and got them debugged and working. Today I changed a value in the spreadsheet, and suddenly all the UDF's displayed #NAME?
Ultimately I decided to start from scratch. I created a new workbook with just one UDF. Here it is, in it's entirety:
Function say7() As Integer
say7 = 7
End Function
I then went to Sheet1 and in box A1 entered "=say7()". I got "#NAME?".
If I type "sa", the dropdown shows "say7". I can press tab or enter and it fills in the function name. And then it says #NAME?.
I understand that Excel 2010 is no longer supported. Did Microsoft do something to break UDFs?
My XLSM was working a few weeks ago. Indeed, the file where I made the change was a copy of the original spreadsheet. I went back to the original, changed a value in one cell that should have forced a recalculation, and it said #NAME?. I didn't change the code, I didn't change any settings, nothing. The only thing I changed was one data value and somehow that makes the function name not be recognized anymore.
Update: Several posters have pointed out that "say7" is not a legal name for a function in Excel and that using this name would produce a #REF? error. True. But my problem was that I was getting a #NAME? error, not a #REF? error. In my attempt to create a simplified scenario -- to make sure that the problem wasn't some error within the function -- I created a new, deliberately very simple function that got the same #NAME? error. Yes, I gave this function an illegal name, which muddles my question. I apologize for the confusion. Explaining why say7 is an invalid name is interesting and useful information, but sadly does not solve my original problem.
When you are writing the function then there are conventional rules of naming it. One of them says
You should not use any names that are identical to the functions, statements, and methods in Visual Basic because you may shadow the same keywords in the language.
The name Say7 while it looks innocuous enough, clashes with a column numbered 12895 which is named as SAY. So in principle, below works for me but I do not have Excel 2010 to see and confirm.
Public Function SaySeven() As Integer
SaySeven = 7
End Function
Edit:
After reading OP's own answer post and other details over, I can think of one more situation where we may encounter #NAME error. This can be reproduced fairly easily.
Step 1: Create a UDF and save the workbook. When you do so, it should not be saved at Excel's trusted locations and the file shall not be identified as trusted. If it is trusted then Excel doesn't prompt for enabling active content. At the point of creation, Excel will produce results without any error. Now close the workbook.
Step 2: Reopen this workbook. You will be prompted with below message.
Ignore this message i.e. do not press "Enable Content" button. OP may have missed this message somewhere.
Step 3: If the UDF was implemented in the previous session and it has returned a valid result then it will not return any error upon recalculation. However, if you enter this UDF in a new cell then Excel will return #NAME error. In below snapshot, both green cell and yellow cell contain exactly the same formula i.e.
=dist3()
But the outcome differs.
So in conclusion: UDF name dist3 is valid and it should work as cited by OP in his later postings. However, in above specific case, one may encounter error of this kind. It will, however, apply to all UDFs and not just dist3.
I have tested this in Excel's Office 365 version but I don't think there will be any major differences in this behavior across versions.
I eventually partly figured it out. At least enough to get it working.
Excel normally blocks you from running UDF's unless you explicitly give it permission. When you try to use the first UDF it pops up a question at the top of the window asking for permission, and if you don't give it, then UDFs aren't recognized and you get #NAME? errors for them.
Apparently -- and this is the part I'm not sure about -- the message telling me that support for Excel 2010 had expired was displayed on top of this message so I couldn't see it. Or something like that. I copied the file to another computer that had a newer version of Excel and I got the message. I clicked OK and the UDFs worked. I then saved it and copied it back to the original computer and it worked fine.
As I had previously clicked Ok on this and this answer is apparently saved with the file, I'm not sure why it asked again. Maybe some changes to the file invalidate the previous answer? I'm not sure.
I created a new file and saw the message about "UDFs ok?" on that one. So maybe my theory that the message was covered by the expiration notice is not correct. I guess it's possible that the message was there all along and I was just blind and didn't see it. That seems unlikely as I was searching for some explanation, but, etc.
In my first version of this post I said that the function name "say7" worked. This was incorrect. When I got the spreadsheet to work I had gone back to my original spreadsheet, where the function that was referenced in the spreadsheet was called "dist3", which works. (There were other functions but they wee all called from within dist3.)
In any case, before I created "say7" I was trying to get it to work with a function called "dist3" and that was also failing with the #NAME?. And as I said in the question, it worked a month ago and I didn't change any function names, so I knew that an illegal function name was not the issue. My attempt to create a simple function to test the problem was a wrong turn because I used an illegal function name that created different problems.
Seeing the logic of #shrivallbha redij's reply I changed the function's name to SAYG (with the idea that G defines the 7th column) and still got a #NAME error. However this can be avoided by passing an argument in the function call, even if the argument isn't used by the function or if it's blank.
=SAYG - returns an error
=SAYG(A1) - returns 7
=SAYG() - returns 7
I am having a weird problem with my excel sheet. It is because I have been trying to use the Index(range;Match();column()) to extract information from a big data set.
The problem is that the above formula, when I apply into one sheet, then it shows #REF. But if I copy/paste or connect the data to another sheet and run the index(match()) command there, then it works like it should. Does anyone have any clue what could be the error?
It is because right now I have a data set of almost 800 rows, and I can not connect it to a second sheet, since I dont want to overburden the file. So has anyone ever faced this issue before with their excel files?
I have used the exact method formula in the second sheet and it works. But it is this one sheet where the problem arises. I have been using vlookup() in the same sheet and it worked fine.
UPDATE
I have also uploaded the result now as well.
I am attempting to create a blank excel file, write a collection to the file and save it at a location. I am able to create a file, however when I run the write collection step I get a generic code error message. I have also noticed that the Save As Step doesn't seem to work correctly. It outputs blank as the Workbook Name. I believe the issue may be linked to a column in my collection which is a set of inserts. The job seems to work when the collection is empty, only producing the error when it is populated.
You've stumbled across issues that can be really tricky to debug.
The issue with the 'Save Workbook As' is a Blue Prism bug that you can fix on your own. Open the action in Object studio and you will notice that the Code stage outputs the result to 'workbookname' instead of 'newworkbookname'. Change that and it will work as intended.
As for the issue with the 'Write Collection', if you say that it works if there are no rows then the values may be the issue. I am not quite fond of the equal sign at the beginning of the value, what happens if it's not there? Have you tried including apostrophe in front of the string to force the value into text and not a function?
Like this:
' = insert into dbo.table ...
I want to reference an external workbook that is open. If I type =path\[file] directly into the cell (even though I am still asked to 'Update Values',) I am able to get the data I require. However, I am using INDIRECT because the name of the file changes everyday (date). So, I am using CONCATENATE to create a filename daily and then using INDIRECT to the cell where the concatenated formulas is. If you paste values to see what is being generated formula, it is exactly the same formula as above, =path\[file]. However, I continue to only get #REF! error.
I read through this, https://support.office.com/en-us/article/control-when-external-references-links-are-updated-87861952-ca9d-4d2a-a986-4d672c908d0d, and I still can not figure it out. I had it working on my computer at home last night but today and work it is giving me trouble.
To clarify, the formula that I am trying to get to work looks like this =INDIRECT("'"&CONCATENATE($F$129,$F$130,F95)) which worked yesterday at home. Can someone lead me in the right direction?
EDIT:
I have tried two options, =INDIRECT(F121) and =INDIRECT("'"&F121). The contents of F121 have been =CONCATENATE("'",F191,F192,F157) and =CONCATENATE(F191,F192,F157), respectively. I have also tried =CONCATENATE("'",F191,F192,F157) in the destination cell. F191 = [Liquidity Risk Dashboard v2.03 -, F192 = =TEXT(E3,"yyyymmdd")&"]", and F157 = Calculations'!D122. If I write ='[BMI Liquidity Risk Dashboard v2.03 - 20170105]Calculations'!D122 am asked to update values but, 100% have both workbooks upon in same instance
If I understand what you really have in your cells, the problem is that you are not properly naming the source workbook.
Try changing
F192: =TEXT(E3,"yyyymmdd")&".xlsb]"
Replace .xlsb with whatever the file extension really is for your file. (eg: .xlsx, .xlsm, .xls)
Who could provide some help in avoiding this error ?
Description:
I create a chart (x-y plot) containing 1 series of data.
I delete this series.
I delete the columns of data holding the source data which has been
used for the (already deleted) series.
Now the error message mentioned above occurs !
Question:
What element do I have to delete from the chart additional to the series in order to avoid this message ?
What I already tried:
The original error was occuring during running a VBA macro. The
message is not coming from VBA --> I can reproduce the error with a
clean workbook, adding a chart manually and removing the series
manually. So it seems to be a general Excel issue.
In the Macro, I tried to add activechart.refresh and
activechart.chartarea.clearcontents and activechart.legend.clear
after deleting the series, before leaving the macro. No success
In this forum there are some similar questions, but the answers
listed here are not really solving my problem (as far as I could
see so far)
There is no other Chart pointing to the deleted data
Setting the datasource property of the chart to "Nothing" is crashing Excel.. don't try this
Hiding one series which remains every time in the chart might be a workaround (thanks to 'Excel Developers'). I'm not able to try it fast, as that would need a quite big amount of reprogramming.
setting the datasource property of the chart to a reference to an empty cell after deleting the last series seems to bring improvement, but no solution. From time to time the error is coming back.
Ihave to find out exactly when :-(
Instead of deleting the last remaining series, I used activechart.chartarea.clearcontents. This solves the issue for some type of Charts. But unfortunately not for all. At this point I have to give up... The error is not critical and won't occur too often.
Any other idea / suggestion ?
Looking forward to your answers / suggestions /hints