Ok here is the issue, i need to open a large workbook from another large workbook, it was working fine till now, and i've not changed it, here is the thing it suddenly started crashing when the full path is on a speciffic location.
the address is fine, the password is fine but then when i get to this line:
Workbooks.Open FileName:=PROJECT_DETAILS_WB_FULL_PATH, UpdateLinks:=True, Password:=PROJECT_DETAILS_DECRIPTION_KEY, ReadOnly:=False 'here is the problem
and excel crashes entirely
-Even while running step by step so the "wait" method isn't it
-I have the same issue with office 2013 and 365 so not an office version issue
-Also tried in different computers and the issue persists.
-Replaced the target file with one that 100% works and still.
-if i open the file manually it works (there is a check for the file been already open)
My guess is that it is a folder permit or file permit issue on the target path, if anyone know what I should check for that would be helpfull
Ok guys and girls, thanks for your help, after poking around all day I found the issue, in summary, file "A" was trying to open file "B" and excel crashed, turns out that file "B" has links to another file, file "C", which was not up to date, those links are to named ranges that didn't exist in the older version of file "C".
When file "B" attempted to check (before "UpdateLinks:=True") excel crashed, updating file "C" to the latest version worked. Note that when prompted to update the links manually, Excel does not crash regardless of what you choose.
Try the following code.
Sub openwb()
Dim wkbk As Workbook
Dim NewFile As Variant
NewFile = Application.GetOpenFilename("microsoft excel files (*.xlsm*), *.xlsm*")
If NewFile <> False Then
Set wkbk = Workbooks.Open(NewFile)
End If
End Sub
Related
When linking workbooks in Excel, I often get an error like:
Links to xxxx.xlsx were not updated because xxxx.xlsx was not recalculated before it was last saved
This error pops up once for every linked value, which means in my case about 100 alerts I need to press OK for. Mysteriously, this alert comes even if xxxx.xlsx contains no formulas and hence no recalculation at all: it's completely full of values only.
So how does Excel know that a file has not been recalculated before saving? Is it looking at a particular xml value inside the ZIP file (xlsx) which I could tamper with? Is it looking at open date vs modified date that I could circumvent with the touch linux command? I'd like a solution Using the command line ubuntu if possible (I run windows WSL), so that I can use a script.
And what's more, xxxx.xlsx is really big, which over network (thanks COVID) at home is slow to open / recalc / save. So I really don't want to ever open this file in Excel.
Any ideas?
You could try adding this macro to your PERSONAL.XLSB file and then running it. It will ask you to select a file and then open it without allowing links to update.
Sub OpenWithoutUpdatingLinks()
Dim strFileName As String
strFileName = Application.GetOpenFilename
If strFileName <> "" Then Workbooks.Open FileName:=strFileName, UpdateLinks:=False
End Sub
This will allow you to open the file you're working on without getting the message about updating links.
However, if you actually need the links to update or need to create more links, then you need the linked file to be recalculated.
Let us know if you need instructions on adding a macro to your personal file and running it.
I have an excel file stored in Sharepoint (which is also accessible with Microsoft Teams), with the path: https://organization.sharepoint.com/PathOfFile/myFile.xlsx
The file can be edited by multiple at the same time with the co-authoring feature in Sharepoint.
I want to use another excel file stored locally in my computer to access and modify the one in Sharepoint. This local file has a button with this VBA code in it:
Sub UpdateSP():
f_name = "https://organization.sharepoint.com/PathOfFile/myFile.xlsx"
Workbooks.Open f_name
Workbooks("myFile.xlsx").Activate
ActiveWorkbook.Sheets("sheet1").Activate
Range("A" & Rows.Count).End(xlUp).Offset(1).Select
ActiveCell.Value = 9999
ActiveCell.Offset(0, 1).Select
ActiveCell.Value = 0000
ActiveWorkbook.Close SaveChanges:=True
End Sub
In principle it works, the file in Sharepoint is modified. But things go wrong if there's someone editing the file while I run the code, then two versions of the file seem to be created, one for the online-live editing, and the one for my code.
If this happens, the online version of the file won't show the changes made by the code, and whenever the file is opened with the excel app, a pop-up will show asking which version of the file should be kept, losing all the changes done in the disposed version.
I have tried to use the CanCheckOut and CheckOut methods, but CanCheckOut always returns False for whatever reason (there are some questions here with the same issue but I havent been able to find a solution).
Can someone suggest a solution to this issue? Thanks.
I'm not 100% sure it will work on SharePoint, but in theory, ADODB is a library for VBA that has the syntax of objects to use Microsoft's Jet Engine so you can open files AdLockOptimistic---ally. ((look up lock types in ADO.net))
This works on a file directory basis, so if the DB being modified is open, it will handle the update.
Instead of using Excel's Application to open the file, you would establish an ADO connection, and then specify the type of Lock in order to access the Excel's sheets and tables inside it.
This works for shared / network drives, so I'm guessing since SharePoint can be mapped as a file explorer drive, then ADO should work and is worth a try.
Here's a basic example to get you started: ADO question
Try enabling the autosave after activating the workbook.
To do so, add this line:
ActiveWorkbook.AutoSaveOn = True
after the Workbooks("myFile.xlsx").Activate line.
I have had similar issues with collaborative files and making sure the autosave is enabled has solved it.
To be able to incorporate changes that way your code must run inside a coauthoring context.
Instead of opening the document from another doc or local copy, the code must be running inside the same document being opened from the same source URL (Sharepoint or OneDrive), that way the add-in or macro can make changes that Excel itself will handle on a coauthoring context.
I recommend taking a look at Coauthoring in Excel add-ins of the Office Dev Center, including the linked articles inside (specifically "coauthoring", redirecting to the support center, and "About coauthoring in Excel (VBA)" at the bottom with more samples).
CanCheckOut will always return false if a workbook is open. Thus you must check before you touch it. The CheckOut command will not open the file so we must also have an open statement after CheckOut.
Using your example it would look like this;
Option Explicit
Public Sub UpdateSP()
Dim fName As String
fName = "https://organization.sharepoint.com/PathOfFile/myFile.xlsx"
If Workbooks.CanCheckOut(fName) Then
Workbooks.CheckOut fName
Dim myFile As Workbook
Set myFile = Workbooks.Open(fName)
Dim mySheet As Worksheet
Set mySheet = myFile.Sheets("Sheet1")
Dim startRange As Range
Set startRange = mySheet.Range("A" & mySheet.Rows.Count).End(xlUp).Offset(1)
startRange.Value = 9999
startRange.Offset(0, 1).Value = 0
myFile.Close SaveChanges:=True
Else
MsgBox fName & " can't be checked out at this time.", vbInformation
End If
End Sub
I'm running into a situation where as soon as I run the following lines of code, my file gets corrupted upon close and re-open.
Dim MyName As Name
For Each MyName In Names
ActiveWorkbook.Names(MyName.Name).Delete
Next
I had also tried to replace the code above with the following, and get the same impact:
Do While CBool(ActiveWorkbook.Names.Count)
ActiveWorkbook.Names(1).Delete
Loop
The error upon re-opening of the file is as follows:
"We found a problem with some content in 'File X.xlsm'. Do you want us to try to recover as much as we can? If you trust the source of this workbook, click Yes'.
After this, the file repairs the file by 'repairing or removing the unreadable content' with message 'Removed Feature: External data range from /xl/worksheets/sheet7.xml part'
Any ideas what's going on here? I'm glad I was able to isolate the code causing the issue, but I'm at a loss. I'm using Excel for Office 365 MSO 32-bit.
You do not define the collection that Names belongs to. Try modifying to define the collection of names.
Dim MyName As Name
For Each MyName In ActiveWorkbook.Names
MyName.Delete
Next
My problem is very strange.
I was programming a macro to open workbooks and extract data which was going fine when it hung one time. I had to end process in task manager and restarted excel.
Now even basic file opening code doesn't work.
My basic code is like this
File path is C:/ and fileName is Book1
Set wbOpen (filePath & fileName)
wbopen.activeSheet.Range ("A1") = "Test"
.close SaveChanges:= True
Msgbox "ok"
.... end sub
The code used to work and i would see book1 being opened on the taskbar and the cell A1 will be changed. Now i still get the Ok message but the cells arent changed and i dont see book1 being opened. Any idea? Pls and thank you
Tried it on another PC and it doesnt work, could be excel settings
Already reset settings using the /regserver method and deleted the .vbe files under AppData too.
Sorry, was a very stupid mistake, must have accidentally set file path to "C:/Excel" instead of "C:/Excel/"
Tracked it down by using the msg box to print out the file im trying to access
We have a product based on a set of Excel workbooks which runs on Excel 2003 onwards. Some of the workbooks open other workbooks in the same directory to use as data stores. Recently, in trying to port this to the Mac Excel 2011 platform, we converted the workbooks from .xls to .xlsm format. After a struggle with a log of compatibility issues, we have the product working on Excel 2007 onwards.
However, when we went back to test on Excel 2003 with the Converter module installed, our self-relative workbook links all break. This is because the converter makes a copy of the workbook in the users Temp directory which is not anywhere near the product directory. The user has a choice of where to install the product, so the path to the product directory has always been self-relative, which has worked fine up until now. Oddly enough, once the workbook is open, if you have run the Workbook_Open code, it returns the correct path. Only when the work book is actually opening, do you have the problem. e.g.
Private Sub Workbook_Open()
Dim appPath As String
Dim FileName As String
. . .
appPath = Me.Path
#If Win32 Or Win64 Then
FileName = appPath & "\" & "MMDataStore.xlsm"
#Else
' MAC support
FileName = appPath & ":" & "MMDataStore.xlsm"
#End If
MsgBox FileName
Application.Workbooks.Open FileName
MsgBox "Activate"
Workbooks("MMDataStore.xlsm").Activate
Me.Activate
...
The first time through, as the workbook opens, the message box indicates the Filename path (appPath) is in the Temp directory (e.g. C:\Users\njohnson\AppData\Local\Temp\MMDataStore.xlsm. If you then open up Microsoft Visual Basic and step through the same workbook open code, it now shows the sheet as being open in the correct directory. Does anyone have any thoughts on how to work around this?
Thanks, Neil
This appears to be a Microsoft bug. Our workaround was to move the code to open the workbook into the function that required it, just as it required it. e.g. When the user wanted to retrieve data from the workbook or store data to the work book, we would check if it was already open, and if not, open it at then. By this time, all of the internal pointers to the workbook seem to have been resolved, and the Workbook open worked correctly. This solution works on Excel 2003 with the converters.