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 ...
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 know that error "We Found A Problem With Some Content In Excel" has been asked a lot of times, but I haven't found my root cause for this problem.
In my excel file this error appears after I switch formula
=IFERROR(XLOOKUP([#Column1];Sheet1[Column2];Sheet1[Column3]);0)
to following formula
=IFERROR(XLOOKUP([#Column1];Value(Sheet1[Column2]);Sheet1[Column3]);0)
Basically, I am just adding Value() function as values in Column2 often appear to be "Number stored as text".
Data is added to the template file (it contains mentioned formulas) using GemBox. The algorithm is I have template, run the app that adds data to the file, then I open file and everything is good.
But as I correct the formula adding Value() function it breaks down as I try to open the file in the last step.
The only thing that comes to my mind is that xlookup function accepts the array of data, so I can't use Value function by passing array into it. But still, if I change my formula manually, it works well
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.
I am new to BluePrism and trying to read Arabic from an Excel sheet. But when I open collection process it shows question marks instead of showing Arabic characters. I tried to write this data into another sheet but it prints the same question mark rather Arabic.
I tried to use the Get Cell Value command and that worked well with Arabic, which lead me to believe the problem isn't with Blue Prism as a whole, but only in the way the Get Range Collection is built.
If you have a look at the VB.NET code behind the action, you see that the BP developers first copy the range into clipboard and then parse the clipboard contents into the collection. That's where the problem most likely occurs.
A quick workaround would be not using the Get Range as Collection at all and use just the Get Cell Value instead, longer workaround would be modifying the Get Range as Collection action.
I can see two options for the longer workaround as well. Either you figure out the problem with the way the clipboard parsing works and fix it, or you change the logic to fill the DataTable directly (for each row and for each column set cell value to Table). The performance will be worse, but it will work).
Probably you need to install the Font on your machine and get the Worksheet as a collection. Or maybe Translate all in English, get it and then translate it in Arabic Again, Or maybe read cell by cell if entire collection isn't working.
It would be helpful to have the worksheet as example.
I'm almost sure I will have to create a new excel file, but maybe at least here I get some ideas what was the source of the problem.
My excel file is constantly giving the following error:
Excel found unreadable content in 'filename.xlsm'. Do you want to recover the contents of this workbook? If you trust the source of this workbook, click Yes.
So I do. And the file opens as repaired showing:
Removed Records: Sorting from /xl/worksheets/sheet10.xml part.
The detail is that I don't even have a sheet10
Its a big excel file full of custom-objects. But I have no DB connections or autofilter so could not relate to AutoFilter Criteria Using Array (Error) - Too Large String? or xlsx error: "Removed Records: Named range from /xl/workbook.xml part" when tried to resolve errors.
Anyone has a clue what's going on?
tks in advance
try clearing the sort before saving down the workbook. When this happened to me I had my sheet references mixed up so the sort wasn't cleared
Sheets(yoursheetname).Sort.SortFields.Clear
I am afraid I cannot explain what is going on, but I had similar experience several times - always with XLSM file. In the latest case I learnt that Excel did not like the same range name used twice, when defined as Worksheet range name (we assumed it is safe to use it that way).
Our troubleshooting path is:
try to save file as XLSB (binary macro file) and either use XLSB file or save it back to XLSM
check file history (we always keep daily snapshots) and find when the problem firstly occurred; use previous version and port your changes
extract the code (via SVN code), create a new workbook and import the code back
Usually Step 1 solves the problem, but Step 3 never failed us.
Awesome,
This issue has been driving me crazy!
It seems that saving as the xlsb (binary) file PLUS adding the clearing of sort fields appears to have sorted out my issue.
I added the following code to the BeforeClose sub, it appears to clear the fields really quick, changes to my Dashboard and prompts for saving.
The xlsb file saved over a mb in file size and appears to load a little quicker!
Thanks for the pointers & support!
Private Sub Workbook_BeforeClose(Cancel As Boolean)
Dim Sht As Worksheet
' Clear all Sort Fields prior to Save & Exit
For Each Sht In Application.Worksheets
Sht.Sort.SortFields.Clear
Next Sht
aa1_Dashboard1.Select
aa1_Dashboard1.Activate
End Sub
I would like to add my own confirmation regarding clearing sort fields in your spreadsheet, as first suggested by Chris. I specifically had the error occur after I used column sorting in a VBA macro, so I deduced that the problem must be column/field-Sort related. It was.
Adding the line:
Sheets(yoursheetname).Sort.SortFields.Clear
after the sort command allowed the sorted columns to remain sorted (in my case), but cleared whatever was causing the
"Sorting from /xl/worksheets/sheet10.xml part." error when the file was next opened.
Many thanks for your support.
I don't know if this will help anyone but it's solved my problem. I had an excel sheet, nothing complex, just contacts, a much used file in Excel 2010 on Win7. Today I was using the 'filter' to select specific groups to email targeted content to. In the middle of selecting and copying to paste into Outlook, the document came up with a pop up as if I was installing something, then the 'installer' both of which I cancelled out of. The Document closed and then on trying to reopen, I was getting the error message. If I chose 'yes' to repair I was given just the subset of my filtered list, so about 40 of my 350 records, the rest lost. I googled and tried different things, including opening in Googledocs google sheets and nothing worked. I never 'saved' the repaired version as my old data wasn't in that. Just now, I right clicked on my document in explorer and chose "restore previous versions" and it brought me to the version of yesterday - thankfully, nothing added to it since then. Opened that one and bingo, it opened fine with ALL the data in it. I know the filter had corrupted it, so will be cautious next time I use it. I don't know why it doesn't like the filter but 4 hours on, i can now calm down and relax! Hope this helps someone.
was having this issue as well. I have a spreadsheet with multiple tabs (maybe 30 tabs?) and had filters on each sheet, and shared on SharedPoint. The error was not enabling editing of the file on SharePoint. I removed the filters on every sheet and uploaded back to SharePoint and the issue is gone!
I did what Chris mentioned above. Clear the sort fields in your spreadsheet.
Sheets(yoursheetname).Sort.SortFields.Clear
Also, save the file as *.xlsb.
That should get it to work.
When you get a message telling that Excel found unreadable.... just click "Open" and then close all the following messages you get.
-In the VBE open the project showing the name of Addin or the .xlsm.. the click anywhere in any module of the workbook as you are going to edit the text of the macro, then click save, select workbook type like Addin select the folder where you want to save it, give it a new name then click "Save", that is all you have to do, the new file you created will ok.