I'm using a java method to download via agent my multipage dashboard to server file system. When I open the downloaded file I get an error "Excel found unreadable contente in "test.xlsx". Do you want to recover the contents of this workbook? If you trust the source of this workboos, click Yes."
When I click on Yes button, I have a warning "Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded."
Data are perfect, nothing is lost, but file is delivered to end users and I can't let it so.
I've tried the same on another environment, where OBIEE 12 is placed, and unfortunately I encounter the same trouble.
I really don't know what to do. We have installed the patch "11.1.1.7.181016" that promises to fix java security trouble in creating the excel file, but with fully unsuccess.
Any suggestion would be great and precious.
Thank you very much.
There's a reason that 11g is outdated and has been replaced with 12c which itself is already on the way out and being replaces by OAS.
The ancient versions have issues that aren't fixed anymore and something that came out in 2013 is expected to not work anymore with other modern software at some point.
It's way beyond time for you to upgrade. And fast. The longer you wait the more problems you incur.
Update: If the bundle patch and the one-off patch 22934699 don't solve the issue then you will be stuck with it.
Alternatively you can switch to CSV for the export since looking at this question here and your other one all you're doing is data dumping.
I'm new to node and am playing around with SailsJS. I found what I think is a bug (reported it), but I wanted to have ago at debuging it myself.
I located the file that I need to investigate in the node_modules folder.
I tried putting a console.log in it to ensure I had the right one. Nothing happened.
So I tried placing log statements in several other files in node_modules that are at the top of the dependency tree. Nothing is printing out.
Do I need to do something to refresh the cache make this work? OR am I going about this in completely the wrong way!
Usually, if you think that an external module has a bug, the best approach is to clone it and write a test that shows which is the offending set of inputs.
SailJS is available on GitHub, so you can freely and easily contribute with a merge request if you find that you are right.
This way, you can adopt the same approach used by the project to test the code (as an example, using mocha).
In case the merge request will be accepted, while waiting for a new release on npm you can refer to your remote copy by means of the package.json file.
I have some Excel worksheets that use ActiveX checkboxes to control certain activity. They worked recently but today started to give errors. I was alerted to this by a colleague, but it was still working on my computer. I checked his version of Excel against mine and his was newer. I noticed there were new Windows updates, so I did the update. After I applied pending updates, it now no longer works on my computer. I cannot check the ActiveX checkboxes any longer, and, as a part of trying to debug, it appears I cannot even add an ActiveX control to any worksheet, even a new worksheet, any more. I get an error dialog that says, "Cannot insert object." (I can still add form controls, just not ActiveX.) Anyone else experiencing this after a recent update? Any suggestions?
Thanks,
Mike
From other forums, I have learned that it is due to the MS Update and that a good fix is to simply delete the file MSForms.exd from any Temp subfolder in the user's profile. For instance:
C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\Word8.0\MSForms.exd
Of course the application (Excel, Word...) must be closed in order to delete this file.
Here is the best answer that I have found on the Microsoft Excel Support Team Blog
For some users, Forms Controls (FM20.dll) are no longer working as
expected after installing December 2014 updates. Issues are
experienced at times such as when they open files with existing VBA
projects using forms controls, try to insert a forms control in to a
new worksheet or run third party software that may use these
components.
You may received errors such as:
"Cannot insert object" "Object library invalid or contains references
to object definitions that could not be found"
Additionally, you may be unable to use or change properties of an
ActiveX control on a worksheet or receive an error when trying to
refer to an ActiveX control as a member of a worksheet via code.
Steps to follow after the update:
To resolve this issue, you must delete the cached versions of the
control type libraries (extender files) on the client computer. To do
this, you must search your hard disk for files that have the ".exd"
file name extension and delete all the .exd files that you find. These
.exd files will be re-created automatically when you use the new
controls the next time that you use VBA. These extender files will be
under the user's profile and may also be in other locations, such as
the following:
%appdata%\Microsoft\forms
%temp%\Excel8.0
%temp%\VBE
Scripting solution:
Because this problem may affect more than one machine, it is also
possible to create a scripting solution to delete the EXD files and
run the script as part of the logon process using a policy. The script
you would need should contain the following lines and would need to be
run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %appdata%\Roaming\microsoft\forms\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be
tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile
VBAProject.
Save and reopen the file. Test for resolution. If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will
also need to have the updates applied on their systems and .exd files
removed as well.
If this does not resolve your issue, it may be a different issue and
further troubleshooting may be necessary.
Microsoft is currently working on this issue. Watch the blog for
updates.
Source
It was KB2553154. Microsoft needs to release a fix. As a developer of Excel applications we can't go to all our clients computers and delete files off them. We are getting blamed for something Microsoft caused.
I'm an Excel developer, and I definitely felt the pain when this happened. Fortunately, I was able to find a workaround by renaming the MSForms.exd files in VBA even when Excel is running, which also can fix the issue. Excel developers who need to distribute their spreadsheets can add the following VBA code to their spreadsheets to make them immune to the MS update.
Place this code in any module.
Public Sub RenameMSFormsFiles()
Const tempFileName As String = "MSForms - Copy.exd"
Const msFormsFileName As String = "MSForms.exd"
On Error Resume Next
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd file
RenameFile Environ("TEMP") & "\Excel8.0\" & msFormsFileName, Environ("TEMP") & "\Excel8.0\" & tempFileName
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd file
RenameFile Environ("TEMP") & "\VBE\" & msFormsFileName, Environ("TEMP") & "\VBE\" & tempFileName
End Sub
Private Sub RenameFile(fromFilePath As String, toFilePath As String)
If CheckFileExist(fromFilePath) Then
DeleteFile toFilePath
Name fromFilePath As toFilePath
End If
End Sub
Private Function CheckFileExist(path As String) As Boolean
CheckFileExist = (Dir(path) <> "")
End Function
Private Sub DeleteFile(path As String)
If CheckFileExist(path) Then
SetAttr path, vbNormal
Kill path
End If
End Sub
The RenameMSFormsFiles subroutine tries to rename the MSForms.exd files in the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\ and C:\Users\[user.name]\AppData\Local\Temp\VBE\ folders to MSForms - Copy.exd.
Then call the RenameMSFormsFiles subroutine at the very beginning of the Workbook_Open event.
Private Sub Workbook_Open()
RenameMSFormsFiles
End Sub
The spreadsheet will try to rename the MSForms.exd files when it opens. Obviously, this is not a perfect fix:
The affected user will still experience the ActiveX control errors when running the VBA code the very first time opening the spreadsheet. Only after executing the VBA code once and restarting Excel, the issue is fixed. Normally when a user encounters a broken spreadsheet, the knee-jerk reaction is to close Excel and try to open the spreadsheet again. :)
The MSForms.exd files are renamed every time the spreadsheet opens, even when there's no issue with the MSForms.exd files. But the spreadsheet will work just fine.
At least for now, Excel developers can continue to distribute their work with this workaround until Microsoft releases a fix.
I've posted this solution here.
With Windows 8.1 I couldn't find any .exd files using windows search. On the other hand, a cmd command dir *.exd /S found the one file on my system.
Advice in KB and above didn't work for me. I discovered that if one Excel 2007 user (with or without the security update; not sure of exact circumstances that cause this) saves the file, the original error returns.
I discovered that the fastest way to repair the file again is to delete all the VBA code. Save. Then replace the VBA code (copy/paste). Save. Before attempting this, I delete the .EXD files first, because otherwise I get an error on open.
In my case, I cannot upgrade/update all users of my Excel file in various locations. Since the problem comes back after some users save the Excel file, I am going to have to replace the ActiveX control with something else.
The best source of information and updates on this issue I could find is in the TechNet Blogs » The Microsoft Excel Support Team Blog (as mentioned):
Form Controls stop working after December 2014 Updates (Updated March 10, 2015)
On March 2015 a hotfix was released in addition to the automated fix-it and manual instructions, and it's available on Windows Update as well.
The latest update and fix from Microsoft:
3025036 "Cannot insert object" error in an ActiveX custom Office solution after you install the MS14-082 security update
STATUS: Update March 10, 2015:
Hotfixes for this issue have been released in the March 2015 Updates for Office 2007, 2010 & 2013.
General info about the problem:
For some users, Form Controls (FM20.dll) are no longer working as expected after installing MS14-082 Microsoft Office Security Updates for December 2014. Issues are experienced at times such as when they open files with existing VBA projects using forms controls, try to insert a forms control in to a new worksheet or run third party software that may use these components.
https://technet.microsoft.com/en-us/library/security/ms14-082.aspx
You may receive errors such as:
"Cannot insert object"; "Object library invalid or contains references to object definitions that could not be found"; "The program used to create this object is Forms. That program is either not installed on your computer or it is not responding. To edit this object, install Forms or ensure that any dialog boxes in Forms are closed." [...]
Additionally, you may be unable to use or change properties of an ActiveX control on a worksheet or receive an error when trying to refer to an ActiveX control as a member of a worksheet via code.
Manual and additional solutions:
Scripting solution:
Because this problem may affect more than one machine, it is also possible to create a scripting solution to delete the EXD files and run the script as part of the logon process using a policy. The script you would need should contain the following lines and would need to be run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile VBAProject.
Save and reopen the file. Test for resolution.
If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will also need to have the updates applied on their systems and .exd files removed as well.
Simplified instructions for end-users. Feel free to copy/paste the following.
Here’s how to fix the problem when it comes up:
Close all your Office programs and files.
Open Windows Explorer and type %TEMP% into the address bar, then press Enter. This will take you into the system temporary folder.
Locate and delete the following folders: Excel8.0, VBE, Word8.0
Now try to use your file again, it shouldn't have any problems.
You might need to wait until the problem occurs in order for this fix to work. Applying it prematurely (before the Windows Update gets installed on your system) won't help.
I did finally find this answer on the official Microsoft KB:
http://support.microsoft.com/kb/3025036/EN-US
No new information here than what we have in previous answers, but at least it acknowledges that Microsoft is aware of the issue.
I know many answers have already been posted for this, but neither one answer independently worked for my site. So here is what worked for me:
Step 1: Uninstall the following updates - KB2920789, KB2920790, KB2920792, KB2920793, KB2984942, KB2596927
Step 2: Hide these updates so they do not get installed on subsequent reboots
Step 3: Delete folder Excel8.0 from C:\Users\<>\AppData\Local\Temp
Step 4: Restart workstatiion (I would also make sure the above mentioned KBs did not inadvertently get applied)
I want to provide an answer that worked as the only thing for me (I realize that I might be the only one ever). I had in one macro that I was calling using the ribbon. It had the following code:
colStore = new Collection
I wasn't aware that it throws an error so I was baffled and tried everything in here. The button just stopped working and I couldn't get it to work. When I noticed the error and corrected it to:
Set colStore = new Collection
It started working again. Absolutely strange if you ask me but maybe it helps someone out there who was as desperate as me.
So, I've got a native vc++ application that we currently have stored in TFS2010 (no SP), and we have finnally gotten to the point after the migration from TFS2005 to TFS2010 where we need to branch the code...
After branching the code, which now in TFS2010 does everything on the server and no longer leaves all of the files checked out on the client machine, and which also did NOT throw any errors of any sort... if we try to open the branch copy of the application we get an error:
"There appears to be a discrepancy between the solution's source control information about some project(s) and the information in the project's files(s). ... blah blah blah"
Now this error is being thrown because inside the project file (vcxproj) the SccProjectName value was not updated as part of the branching, so it is still pointing to full path of the trunk source location. Although when it throws this error it will prompt for a check-out and will update the value to the correct value... but it's will be annoying for it to happen every time we branch and there's no way to change it before it throws the error.
Online in various places the 'solution' (I use this term loosely because it doesn't work...) is to change the SccProjectName to "SAK" so that it will use the value in the mssccprj.scc hint file, however the TFS plugin doesn't use a mssccprj.scc hint file... so it will continue to throw the error...
So is there another solution to this issue? or does anybody know if the TFS2010 SP1 fixes this issue?
I had the exact same problem when moving code around in TFS 2010. Here is the solution that I found to work:
It is easier to do this by selecting the solution in Solution Explorer, going to File -> Source Control -> Change Source Control and then unbinding everything. Close the dialog, then re-open it and rebind everything. Save the changes and compare the VCXPROJ files now. The server path and the rest of the TFS info has been removed and replaced with SAK.
Source: http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/786d7d3e-5182-4452-b49b-3436de6f9c36/
We have a lot of VBA code in spreadsheets and a lot of time people save them to local drives. When we want to upgrade the spreadsheets we push a new version out to a shared drive but dont have any way of enforcing that people dont use the old versions of the spreadsheets.
Is there some best practice here to deploy vba spreadsheets so if someone loads an old version it wont open or will ask you to upgrade. It seems like this must be an issue for any custom solution so i would have through MS would have some solution here.
Does microsoft have a standard versioning / deployment solution for this or do i need to come up with some home grown solution (spreadsheet pings a database on startup to check version)
If its just the VBA code you want to be able to upgrade one solution is to separate all the code into an XLA that sits on an accessible server.
then the users Excel has an addin loader that gets the latest version from the server, or you could embed the loader in the workbook.
There is a working example reversioning Addin Loader available at
http://www.decisionmodels.com/downloads.htm
Though I've not done this. I've see people do something similar where they store the code in dlls in the database, and then verify that the local ones are the same on start up.
Add a custom property to the workbook, such as a GUID, Integer, Date, or whatever you need. On startup, check the value and determine if VBA should continue or whatever implementation you decide. Usually, I open the "shared" latest version of the document and inspect its custom property. If user is not using latest version, display a message prompting the user to get the latest version. This is usually good enough. I have done this for years with great success for Access, Word, and Excel VBA.
One real problem is people who ignore the prompt to update. They will do this because they fear losing data, bugs in latest version, and so on. You need to address their concerns and not try to "lock" them in to your "solution" to this problem. I strongly recommend you always provid a means of "importing/upgrading" data to latest version of workbook.
Fairly simple to implement. If you address the above mentioned problem effectively, people will start to trust the "prompt" and you will find this is a really simple and effective solution.
If you workbook is tied to a database, it gets a little more complicated. Generally, you do not allow the user to maintain the data outside of the database. When they want to modify the data, you generate the workbook for them. After they are done modifying data, you import the data. (The workbook is saved for "backup" purposes or the user can maintain a copy of the workbook for reference or an archive.) This has the advantage of eliminating the need to maintain document version since the document is "virtual".
Define a current version property. Use whatever way for that, like a constant in VBA.
Find a standard way to access the latest version. It could be on a shared drive always on the same path, or whatever other means you have.
If current version number < latest version number then:
Ask to upgrade
Show the upgrade procedure
Possibly do some locking on normal VBA operations until the upgrade is done
An easy solution would be:
Store a version number somwhere in the workbook (on a hidden sheet for example so that it will not get removed accidentally) or as a variable.
Store a text file with the latest version number on your share
Include a macro which automatically reads the latest-version-textfile and compares the version number to the one in the currently running workbook. If its too old just show a message-box (telling the user to update) and close the workbook.
I'm using a similar approach and it works fine.