ActiveWorkbook.Save saves to wrong directory

[Jerry Eco]

ActiveWorkbook.Save creates a new spreadsheet in Documents instead of saving
the spreadsheet in its current location. I am using Excel 2007 with a 2003
file (.xls).

The macro is in personal.xlsb and is used to make a few minor fixes to the
active spreadsheet. I want to save the active spreadsheet before I make
those fixes, in case something goes wrong. But, it needs to save it in
place, not create a new file somewhere else.

Thank you.
Jerry

 

[GS]

bruce2g expressed precisely :

I have the same problem. We have a bunch of spreadsheets, and from
time to time save them all by looping through workbook.save

Unfortunately, every once in a while, a spreadsheet will be saved to
the wrong directory! I don't think the user could have done it -
they're not sophisticated enough to do a 'save as' and look through all
the options.

What I've done as a workaround has been to do a saveas and explicitly
say what the folder is. I also had to inhibit the message about
replacing a file with application.displayalerts = false before the
saveas and .. = true afterwards.

I think there's a bug with windows 7 and excel 2007 that causes this,
I'd like to know if anyone else has encountered this problem.

Bruce

<FWIW>
Have you considered storing the path where the file should be saved in
CustomProperties of the workbook? That would allow you to read this
into your SaveAs proc and no worries about getting it written to the
correct location.

 

[Akihito Yamashiro]

Check if the book is saved on a file system.
ActiveworkBook.Path can be used for the purpose.

Sub Main()
If ActiveWorkbook.Path = "" Then
MsgBox "Save the file before the process."
Exit Sub
Else
ActiveWorkbook.Save
'Do something here.
End If
End Sub


If this doesn't help you, the file may be in the 'Program Files'
folder and the PC is Windows Vista or 7,
the file path may be redirected to the VirtualStore folder.

 

[GS]

Akihito Yamashiro brought next idea :

Check if the book is saved on a file system.
ActiveworkBook.Path can be used for the purpose.

Sub Main()
If ActiveWorkbook.Path = "" Then
MsgBox "Save the file before the process."
Exit Sub
Else
ActiveWorkbook.Save
'Do something here.
End If
End Sub


If this doesn't help you, the file may be in the 'Program Files'
folder and the PC is Windows Vista or 7,
the file path may be redirected to the VirtualStore folder.

How does this get the correct path? If files are currently saving to
incorrect folders then the 'assumed path' has to be removed from the
equation. Storing the correct path for a workbook as a CustomProperty
in the workbook file allows code to retrieve it without assumption.

While bruce2g states his users aren't savvy enough to use SaveAs to
save files to the wrong folder, doesn't meant that someone isn't
deliberately moving files from one place to another. Using the
CustomProperty approach means the correct path is imbedded in the xls
file, so no matter where it's opened from it can always get saved back
into the correct folder via code.

 

[Akihito Yamashiro]

Hi, Gary.
The same can be said of your idea.
How does the CustomProperty give the right path?

 

[GS]

Akihito Yamashiro laid this down on his screen :

Hi, Gary.
The same can be said of your idea.
How does the CustomProperty give the right path?

Hi Akihito,
This property would be normally set (manually) when the workbook is
created. The practise of using the CustomProperties is common where
workbooks belong to a specific addin and we want to store information
that identifies the workbook to the addin. In this case, the addin
could retrieve the CustomProperty where the author stored the path to
where the workbook is to be saved. This, of course, would be a string
value that may (or may not) include a preferred SaveAs filename.

An example of where this might apply is a XLT that gets opened
periodically by an addin for entering period data and then gets saved
to a specific folder. In this case the stored path would not include a
filename since it's likely the period date would be used in the
filename.

Another benefit of using this concept is that no file dialogs are
needed, and there's no chance for user input (erroneous or not) into
the process.

Otherwise, this info could (but not preferred) be stored in
workbook-level defined names. This could be a problem when copying
sheets between workbooks. Always using sheet-level names and
CustomProperties obviates any conflict issues rising from using
workbook-level names.

 

[Akihito Yamashiro]

Hi Garry.

According to your idea, the property of the files saved in the wrong
folders has to be MANUALLY set.
Is there any difference between adding the custum property to each
files manually
and resaving each files to the correct folder manually?

Which is better depends on the situation.
But , since Jerry and Bruce2G has not come back again,
we cannot know for further information.

 

[GS]

Akihito Yamashiro explained on 6/23/2010 :

Hi Garry.

According to your idea, the property of the files saved in the wrong
folders has to be MANUALLY set.
Is there any difference between adding the custum property to each
files manually
and resaving each files to the correct folder manually?

Which is better depends on the situation.
But , since Jerry and Bruce2G has not come back again,
we cannot know for further information.

If I understand the OP's scenario correctly, I suspect the problem lies
in that the VBA project is used in a corporate setting AND the
workbooks being saved are pre-existing. In this case my idea works in
that the file save process can be handled entirely by code without
intervention by corporate users of the workbook. This assumes that the
person in charge of the VBA project is not the typical user, and so
precludes that the desired scenario is to have as little user
intervention toward the management of the project (or its files and
their storage locations) as possible.

In summary, you could pre-design a workbook for a particlar purpose and
set some workbook-level 'program' controls in its CustomProperties.
When users of the VBA project open the workbook (presumably via a
dedicated proc rather than the Open dialog), they can do whatever
duties they have to do and save it (presumably via another dedicated
proc). Job done!
</>

Where a template workbook with multiple sheets is used, and each sheet
gets saved to a separate file, the path can be stored in a sheet-level
defined name OR in a dedicated cell somewhere on the sheet.

Also, multiple file save paths could be stored in an external file
(like txt) and retrieved at runtime for processing without user
intervention in the location where to save the file.

Of course, all of these suggestions preclude that the project and all
of its files are pre-designed before users get access. The OP suggests
that the problem with the save to location is in Excel2007 when new
workbooks are being saved for the first time. I'm suggesting use of a
template for creating the new workbook so that the save to location is
already there for the VBA project to process. If it's not there, then
the project has to have some other way of knowing what the save to path
is, and either write this to the CustomProperties so it's there for
future use or just save to that location via a dedicated proc. It would
be a good idea to either disable or 'hook' Excel's UI save methods
while the project runs so that only the project's save routine is used
regardless off how it's initiated.

Optionally, you can always use VBA's ChDir() to set the default path if
you want to preset where the SaveAs dialog opens to when they save via
the UI or your project uses VBA's Save method without implementing any
of this pre-designed stuff. In either case the user has control as to
where the file is saved. The OP states that files are being save to the
wrong place, which indicates to me that having some control over the
save process is needed or should be handled without user intervention.

 

[absolute.ivor]

I have a collection of complex applications from a textile inventory system (600+ active workbooks), a sales reporting system (300+ activeworkbooks) and other "modules" all running off seperate "macrofiles" where each application has its workbooks saved to their own dedicated folders on the server.
The server is accessed and used by almost 30 staff simultaneously and ALL entry, new workbook creation, etc. is done through forms programmatically. The users NEVER intervene and manually save files. I am having the same problem that about twenty/thirty files a month get saved into incorrect folders, not always "MyDocuments", and to date nobody has an answer. There is little to no possibility that the users are working with read-only files. I do suspect that it could relate to an actual file being modified becomes "locked" and the VBA then saves to a/the currently selected/active folder, sadly, without warning.

 

[cwild]

I had the same problem but now I have resolved it as follows:

1. The problem originates when you move or copy a file to a new place.
2. Though it is now in a new place the metadata of the file only knows the last place it was saved at.
3. So if you run VBA save it will save in the last place (old path).
4. To fix it simply resave the file manually before you run your VBA script.
5. Eg. You create a file in C:\Docs and it works fine. Later you make a copy of the file and put it in C:\Working. When you open this new copy you must immediately save it again. Now the metadata knows it is in C:Working and the VBA save will save in the right place.

Cameron Wild.