I have a process that generates multiple spreadsheets. It doesn't save them, which is fine because Normally they would be saved manually.
I want to write a macro that accesses each sheet sequentially, perform some magic and then save and close the sheet.
When using Excel 2016, this is not an issue.
But I have Excel 2010 at work, and it cant see any of the work books.
With Excel 2016 this method works:
Workbooks("Book3").sheets("B3T1").activate
ActiveWindow.WindowState = xlMaximized
with Excel 2010 this is the message I receive:
Workbooks("Book3").sheets("B3T1").activate
runtime error '9'. Subscript out of Range
What is the method I should use to open an external workbook
Thanks, in advance
Assuming the workbook being accessed is already saved at a location.
This will open the external Files and access them. The macro will also close and save the file.
Dim wb As Workbook
Dim fileloc As String
fileloc = "" & "C:namenamename" & ".xlsm" & ""
Set wb = Workbooks.Open(fileloc)
wb.Worksheets("Sheet1").activate
wb.Close savechanges:=True
The worksheet isn't saved by the process that generates the work sheet. That is a manual operation. There are 100 worksheets and I wanted a way to avoid having to maximize each sheet/process it/save it.
The GetObject method finally worked:
For ptr = 1 To 100
Set xlApp = GetObject("Book" & ptr).Application
xlApp.Application.Workbooks("Book" & ptr).Sheets(1).Activate
do some processing
xlApp.Application.Quit
next
A one hour+ process is now reduced to 1 second
Related
I have code in workbook A that opens and does stuff to workbook B. Code runs fine when workbook A and B are the only excel files open (or if workbook A is the only file open). However, if I open up any additional workbook (call it workbook C), the macro does not run correctly. It doesn't cause an error message, it just runs to completion without doing any of the "stuff" it's supposed to do (the stuff is basically finding things in workbook B and pasting them into workbook A).
FWIW, I have done the following simple experiment:
Open all 3 workbooks (A, B, & C)
select workbook C so that it is active and the front window
run the code workbookB.sheet1.activate (this is not verbatim, I know this code as written will fail)
When I do the above test, it doesn't even make workbook B the active workbook. Again, it doesn't cause excel to throw an error message, it just runs and leave workbook C as the active workbook.
Edit: I've tested more, the code below should change the value of a cell in workbook B, but instead is putting the value into workbook C. I am very confused, since workbook C is not referenced in any way (the module is in workbook A)
Sub test()
Dim wb As Workbook
Set wb = Workbooks.Open("U:\workbookB.xlsx")
wb.Worksheets("ED").Range("Z1").Value = "TEST"
End Sub
Edit 2: The issue was occurring when Workbook A and B had been open for several hours, and Workbook C was recently opened. I closed workbook B then re-ran the code and it is working correctly. This leading me to believe that there IS some sort of issue with multiple instances of excel opening. While this is hopefully low-risk, I am still curious if anyone has some way I could code around it as a precaution? Thanks!
There is a subtle bug (I hesitate to call it that, but that's what it looks like) you need to watch out for.
If the workbook you're trying to open via code is already open then occasionally you will see some unexpected behavior (such as the return value from Workbooks.Open() being assigned to ThisWorkbook instead of the file you expect).
For example the code below runs in "Tester.xlsm" and is opening "EmptyTest.xlsx", but if that file is already open, the Workbooks.Open call fails to correctly assign the wb variable, and it ends up pointing at "Tester.xlsm". That can cause problems.
To replicate,
open Excel
open "EmptyTest.xlsx"
open "Tester.xlsm"
run "Tester" sub
Test code:
Sub Tester()
Dim wb As Workbook
'with "EmptyTest" already open
Set wb = Workbooks.Open("C:\Tester\EmptyTest.xlsx")
Debug.Print wb.Name '>> Tester.xlsm - oops!
'close"EmptyTest" before proceeding
Workbooks("EmptyTest.xlsx").Close False
'with "EmptyTest" closed
Set wb = Workbooks.Open("C:\Tester\EmptyTest.xlsx")
Debug.Print wb.Name '>>EmptyTest.xlsx - OK
End Sub
Totally reproducible on my system (win10/Office 365)
I think your problem is that you are opening Workbook B. You state, if you close and re-open it then it works.
Therefore, any changes you have made to Workbook B will be lost as it will re-open the original workbook. (Auto Save does not actually save the workbook, it saves a separate copy.)
You need instead to check if the workbook is already open and only re-open it if it is not currently open.
(Very rough code)
Sub test()
Dim wb As Workbook
For Each wb In ThisWorkbook.Application.Workbooks
If wb.Path & "\" & wb.Name = "U:\workbookB.xlsx" Then Exit For
Next
If wb.Path & "\" & wb.Name <> "U:\workbookB.xlsx" Then Set wb = ThisWorkbook.Application.Workbooks.Open("U:\workbookB.xlsx")
wb.Worksheets("ED").Range("Z1").Value = "TEST"
End Sub
But (as others have said) you should really check that there are no other instances of Excel running and account for them also.
I have a huge Excel spreadsheet that I need to allow access to a large set of users so they can manipulate it for their customers, but I don't want them to be able to overwrite the original file (a variable easily set in Excel) or save their file outside the current folder - so I want to force them in a "saveas" mode, and force the file to be saved in that folder. Otherwise, they won't be able to save. I'm not much of a VBA person, and I've found a lot of examples that may work, but nothing seems to be exactly what I need or maybe I'm not smart enough to figure it out. I found this code, but I'm not sure it FORCES the issue. Help?
I've tried to manage this in GPOs but everything seems to give them access to download the folder and save in other places.
Sub ExampleToSaveWorkbookSet()
Dim wkb As Workbook
'Adding New Workbook
Set wkb = Workbooks.Add
'Saving the Workbook
wkb.SaveAs "C:\WorkbookName.xls"
'OR
'wkb.SaveAs Filename:="C:\WorkbookName1.xls"
End Sub
Expected output is the amended Excel file saved in the original directory with a different name, or not at all.
Here's a macro that runs on open and immediately saves as .xlsx to a user location you can specify. Unfortunately the original needs to be .xlsm to store a macro.
This macro is to be located in the "ThisWorkbook" object. It will exit before making a copy when you open the workbook.
Private Sub Workbook_Open()
Dim wb As Workbook
Set wb = ActiveWorkbook
vWbName = wb.Name
vUserProf = Environ("USERPROFILE")
vx = InStr(1, vUserProf, "Users\")
If "<Use your own profileID>" = Mid(vUserProf, vx + 6) Then Exit Sub
vDir = vUserProf & "\Downloads\"
vWbName = Left(vWbName, Len(vWbName) - 5) & ".xlsx"
wb.SaveAs vDir & vWbName, FileFormat:=xlOpenXMLWorkbook, CreateBackup:=False
MsgBox "You are now using a copy of the original"
End Sub
I need to call and execute VBA in an Excel spreadsheet from an Access form+button using VBA.
I have several Excel spreadsheets that are connected to my Access DB. I created a separate DB with VBA (C:\CDR & Project Inventory Reports\RebuildDB) to refresh and rebuild my source databases and report workbooks. I also created a separate workbook to refresh all of my other reports (C:\CDR & Project Inventory Reports\RefreshReports). Module 15 of that .xlsm will call all of my other modules to refresh those reports.
Prior to executing the Excel portion of the code is all of my code pertaining to rebuilding the DB. Currently, the Excel portion looks like this:
Dim oXLApp As Object
Set oXLApp = CreateObject("Excel.Application")
oXLApp.Visible = True
oXLApp.Workbooks.Open ("C:\CDR & Project Inventory Reports\RefreshReports.xlsm")
Debug.Print "Open report refresh code"
Debug.Print "refreshing all spreadsheets"
oXLApp.Run "RefreshReports.Module15" 'refreshes all CDR and Proj Inv spreadsheets
DoEvents
Debug.Print "Refresh completed"
oXLApp.ActiveWorkbook.Close (True)
oXLApp.Quit
Set oXLApp = Nothing
Debug.Print "Release object"
The problem I'm having is that oXLApp.Run doesn't actually execute the VBA it needs to. It calls it, then immediately closes. Is there any other way to call it that would result in the code actually running?
oXLApp.Run "RefreshReports.Module15"
should be
oXLApp.Run "RefreshReports.xlsm!NameOfMySub" '// Change sub name as required
As it stands, your code isn't running any VBA from Excel because you haven't referred to a specific sub. I presume you have error handling switched off as this should be rather noticeable.
You should fully qualify the sub to be executed, by also giving the module name
so
oXLApp.Run "RefreshReports.Module15"
should be
oXLApp.Run "'RefreshReports.xlsm'!Module15.NameOfMySub"
If you use
oXLApp.Run "'RefreshReports.xlsm'!NameOfMySub"
and
the procedure NameOfMySub is declared in more than one module
you will get and error message.
You could also re-write your code thus:
Dim oXLApp As Object
Dim Wkbk as workbook
Set oXLApp = CreateObject("Excel.Application")
oXLApp.Visible = True
set Wkbk = oXLApp.Workbooks.Open ("C:\CDR & Project Inventory Reports\RefreshReports.xlsm")
Debug.Print "Open report refresh code"
Debug.Print "refreshing all spreadsheets"
oXLApp.Run "'" & Wkbk.Name & "'!Module15.NameOfMySub"
' Note use of single speechmarks arond workbook name
I'm currently working at a Uni project using Excel VBA and I'm trying to find a way to create an excel that will self destruct if it doesn't find the "Key". And in the event it's entirely impossible, then at least ensure there's none of the data or VBA code left.
The idea is that, using
Private Sub Workbook_Open()
Dim direct As String, name As String
name = ActiveWorkbook.Name
ChDir ThisWorkbook.Path
direct = ThisWorkbook.Path
Call Checker(direct, name)
End Sub
Upon opening the excel, it will look for "Key.txt" which should be within the same folder as the excel and check if the one string of text inside the document matches with "Code" which is a "Public Const" inside the project.
I've been trying to find a way to read the "Key.txt" without opening it, but haven't turned up anything.
On the other hand, I've been testing out various ways of making the program delete the original excel file, varying levels of success. So a somewhat roundabout way I've been testing out is to have the excel SaveAs a ".xlsx" and erase the original file before closing itself, but it doesn't work out as I've hoped for.
This is the code I've used for the "Self-Destruct" method:
Option Explicit
Function Checker(MyPath As String, name As String)
On Error Resume Next
Application.DisplayAlerts = False
Dim myPath2 As String
Dim ws As Worksheet
Dim FSO As Object
myPath2 = MyPath
ActiveWorkbook.SaveAs Filename:=MyPath & "\0_0.xlsx", FileFormat:=xlOpenXMLWorkbook, CreateBackup:=False
Sheets.Add After:=Sheets(Sheets.Count)
ActiveSheet.Name = "1"
For Each ws In Worksheets 'Deletes all other sheets
If ws.Name <> "1" Then ws.Delete
Next
Set FSO = CreateObject("scripting.filesystemobject")
If Right(MyPath, 1) = "\" Then MyPath = Left(MyPath, Len(MyPath) - 1)
If FSO.FolderExists(MyPath) = False Then MsgBox MyPath & " doesn't exist"
FSO.deletefile MyPath & "\" & name, True 'Deletes original file
ActiveWorkbook.Save
ActiveWorkbook.Close
End Function
Having a self-destructing file is an interesting idea. The short answer is that you cannot delete a running VBA macro. Therefore, no VBA macro can essentially self destruct. Yet, there are two options I can think of:
(1) Remove everything but the running macro. The following code might be helpful to achieve that.
http://www.erlandsendata.no/english/index.php?d=envbavbedeleteallmacros
(2) Close the file and ask Windows to delete the file afterwards for you using the task planner. The following post on SO might be able to help with that.
Using Excel vba Macro to be run through Windows Schedule Task
Other tempting solutions might be to save the file as .xlsx or to create a new Excel file, copy the above code from option 1 into that file, call the newly created code, which essentially deletes the original file.
But the real questions I'd ask myself would be: How did this person got the self-destructing file? Was it by email and the file is still in the email? Has the file been duplicated along the way? Are there hidden copies in some Temp-Folders (remember Excel Auto-Safe every xx minutes in case of computer crash to preserve your work)? Is the person enabling macros when opening the file (to allow self-destruction)? Can the person resore the file with the many free programs out there to recover files from a Windows machine (extremely easy as Windows does not delete the file or writes cryptical data on top to ensure it cannot be recovered, but merely "marks" that space on the HD where the file was as free to use for the next file to come)?
I want to search through existing Excel files with a macro, but I don't want to display those files when they're opened by the code. Is there a way to have them open "in the background", so to speak?
Not sure if you can open them invisibly in the current excel instance
You can open a new instance of excel though, hide it and then open the workbooks
Dim app as New Excel.Application
app.Visible = False 'Visible is False by default, so this isn't necessary
Dim book As Excel.Workbook
Set book = app.Workbooks.Add(fileName)
'
' Do what you have to do
'
book.Close SaveChanges:=False
app.Quit
Set app = Nothing
As others have posted, make sure you clean up after you are finished with any opened workbooks
If that suits your needs, I would simply use
Application.ScreenUpdating = False
with the added benefit of accelerating your code, instead of slowing it down by using a second instance of Excel.
To open a workbook as hidden in the existing instance of Excel, use following:
Application.ScreenUpdating = False
Workbooks.Open Filename:=FilePath, UpdateLinks:=True, ReadOnly:=True
ActiveWindow.Visible = False
ThisWorkbook.Activate
Application.ScreenUpdating = True
Using ADO (AnonJr already explained) and utilizing SQL is possibly the best option for fetching data from a closed workbook without opening that in conventional way. Please watch this VIDEO.
OTHERWISE, possibly GetObject(<filename with path>) is the most CONCISE way. Worksheets remain invisible, however will appear in project explorer window in VBE just like any other workbook opened in conventional ways.
Dim wb As Workbook
Set wb = GetObject("C:\MyData.xlsx") 'Worksheets will remain invisible, no new window appears in the screen
' your codes here
wb.Close SaveChanges:=False
If you want to read a particular sheet, need not even define a Workbook variable
Dim sh As Worksheet
Set sh = GetObject("C:\MyData.xlsx").Worksheets("MySheet")
' your codes here
sh.Parent.Close SaveChanges:=False 'Closes the associated workbook
A much simpler approach that doesn't involve manipulating active windows:
Dim wb As Workbook
Set wb = Workbooks.Open("workbook.xlsx")
wb.Windows(1).Visible = False
From what I can tell the Windows index on the workbook should always be 1. If anyone knows of any race conditions that would make this untrue please let me know.
Even though you've got your answer, for those that find this question, it is also possible to open an Excel spreadsheet as a JET data store. Borrowing the connection string from a project I've used it on, it will look kinda like this:
strExcelConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & objFile.Path & ";Extended Properties=""Excel 8.0;HDR=Yes"""
strSQL = "SELECT * FROM [RegistrationList$] ORDER BY DateToRegister DESC"
Note that "RegistrationList" is the name of the tab in the workbook. There are a few tutorials floating around on the web with the particulars of what you can and can't do accessing a sheet this way.
Just thought I'd add. :)
The problem with both iDevlop's and Ashok's answers is that the fundamental problem is an Excel design flaw (apparently) in which the Open method fails to respect the Application.ScreenUpdating setting of False. Consequently, setting it to False is of no benefit to this problem.
If Patrick McDonald's solution is too burdensome due to the overhead of starting a second instance of Excel, then the best solution I've found is to minimize the time that the opened workbook is visible by re-activating the original window as quickly as possible:
Dim TempWkBk As Workbook
Dim CurrentWin As Window
Set CurrentWin = ActiveWindow
Set TempWkBk = Workbooks.Open(SomeFilePath)
CurrentWin.Activate 'Allows only a VERY brief flash of the opened workbook
TempWkBk.Windows(1).Visible = False 'Only necessary if you also need to prevent
'the user from manually accessing the opened
'workbook before it is closed.
'Operate on the new workbook, which is not visible to the user, then close it...
Open the workbook as hidden and then set it as "saved" so that users are not prompted when they close out.
Dim w As Workbooks
Private Sub Workbook_Open()
Application.ScreenUpdating = False
Set w = Workbooks
w.Open Filename:="\\server\PriceList.xlsx", UpdateLinks:=False, ReadOnly:=True 'this is the data file were going to be opening
ActiveWindow.Visible = False
ThisWorkbook.Activate
Application.ScreenUpdating = True
End Sub
Private Sub Workbook_BeforeClose(Cancel As Boolean)
w.Item(2).Saved = True 'this will suppress the safe prompt for the data file only
End Sub
This is somewhat derivative of the answer posted by Ashok.
By doing it this way though you will not get prompted to save changes back to the Excel file your reading from. This is great if the Excel file your reading from is intended as a data source for validation. For example if the workbook contains product names and price data it can be hidden and you can show an Excel file that represents an invoice with drop downs for product that validates from that price list.
You can then store the price list on a shared location on a network somewhere and make it read-only.
Open them from a new instance of Excel.
Sub Test()
Dim xl As Excel.Application
Set xl = CreateObject("Excel.Application")
Dim w As Workbook
Set w = xl.Workbooks.Add()
MsgBox "Not visible yet..."
xl.Visible = True
w.Close False
Set xl = Nothing
End Sub
You need to remember to clean up after you're done.
In excel, hide the workbooks, and save them as hidden. When your app loads them they will not be shown.
Edit: upon re-reading, it became clear that these workbooks are not part of your application. Such a solution would be inappropriate for user workbooks.