I'm trying to automatically save workbooks using VBA to a Sharepoint folder- which needs to be created first.
Code I have below works ONLY for saving the file. The MkDir function returns a Run-time error 76: Path not found. I'm at a loss what causes this error, because the path before /txt DOES exist and I do have the right permissions to add new folders by hand. I have also tried replacing the current path with \ instead of /, but other than making the code significantly slower this has no effect. No "solutions" online have done the trick for me.
Any ideas?
MkDir "https://placeholder.sharepoint.com/teams/Services_NL/Shared Documents/txt"
DateAndTime = Left(Replace(Replace(Replace(Now, " ", "_"), ":", ""), "/", ""), Len(Replace(Replace(Replace(Now, " ", "_"), ":", ""), "/", "")) - 5)
ActiveWorkbook.SaveAs "https://placeholder.sharepoint.com/teams/Services_NL/Shared Documents/Export/" & ExportSheet & DateAndTime & ".txt", FileFormat:=xlTextWindows
I had tried all different combinations of forward slash and backslash, "https://"...etc. But I finally got the MkDir command to work using the following syntax:
MkDir "\\mysite.sharepoint.com\IS\Shared Documents\My Docs\" & "MyNewFolder"
Note: Replace any %20 (used by Sharepoint to substitute a blank space in the URL) with a blank space. Or better yet, copy the folder address directly from the Windows Explorer navigation bar and then add the backslash to the end of it.
Also, I believe its important to first test the ability of your environment (permissions or otherwise) by opening your Sharepoint directory folders within Windows Explorer and navigating through them as a test. If you can do this, then MKDir command should work because you've proven the file directory is accessible.
The "Open with Explorer" icon is found on the Library tab within Sharepoint (I'm using Office 365). I've found that in some Sharepoint environments I've worked with the Library tab is accessible by default, but in others it is hidden (only the Browse and Page tabs are viewable). In that case, I got the Library (and Files) tab to appear by navigating into a Sharepoint folder, highlighting a bunch of files, and then just right-clicking on the highlighted section without clicking on any of the flyout options. Odd behavior, but it worked.
I am having the same issue, using Office 365 from both Win 7 and Win 10 to Sharepoint 2013. It may relate to a security feature which interferes with file System Object actions to online addresses with VBA, resulting in
error 76 path not found; and error 70 permission denied; and also
error 52 bad file name.
We have several Win 10 Office 206 users with VBA, macros, trusted locations, user permissions, explorer navigation, UI folder creation, etc are all fully functional, and set in MSWord and SP2013: errors 70, 76 and sometimes 52 result when the VBA tries to Save As to the Sharepoint folder they all have unfettered access to.
The same users, running Office 2010, to the same server, using the same VBA, have no problems with file system Object saving, navigation etc.
I have found that mapping and un-mapping the Sharepoint 2013 path/drive/folder, in the session with VBA seems to make it work. I tried that on Fri Feb 22 2019. In the VBA immediately before the navigation and creating folders code, I mapped the Shared Documents library to the next available drive (step through if exist for drive-letters 67 to 89, then do the Save As, then remove the mapping. I'll be testing more tomorrow Mon Feb 24 2019.
my path string is: \\sp.url#ssl\davwwwroot\site\subsite\shared%20documents
and the drive letter as noted is dynamic based on whatever the user has.
The path in my string therefore is using teh WebClient service, and that has been very reliable for me under SP2013. until Office 365/Office 2016 that is.
WebClient and Office 2016/365 in Windows 10: I have encountered exactly the same set of circumstances moving from Win 7 + Office 2010 to Win 10 + Office 2016/365. FileSystemObject activity using WebDAV now does not work with the (former fully functional) WebDAV path \sitename#ssl\davwwwroot\site.
I get error 70, 76 when attempting to traverse the path, or create a file system object on that path. Mapping and unmapping works, but wow - that seems a redundant and clunky procedure when the path is already authenticated, apparently except to WebClient.
Adding AuthForwardServerList as new Multistring DWORD parameter to HKLM CurrentControlSet Service WebClient makes the system function, but I cannot state that it will always allow the FileSystemObject to be created, even if the path is mapped ; see https://support.microsoft.com/en-us/help/943280/prompt-for-credentials-when-you-access-webdav-based-fqdn-sites-in-wind
I think the path problem is a Win 10 system issue.
An additional problem is Access Denied, which I think is due to a security "feature" in Office 2016/365, I think intended to control FileSystemObject activity in online locations.
Related
I am receiving the Run-time error '52' bad file name or number error, however all of the questions which cover this on stackoverflow that I can see have answers which involve changing the code. The problem with this is that the code uses a directory in a network drive, and the error doesn't occur on other computers on the network.
It is perhaps worth noting that my computer until recently did not have an activated version of windows due to a complication, however I assumed that to be the cause of the error but it is still occurring after activation.
I have no experience with Microsoft Visual Basic and did not write the code so if you need any more information just ask.
Private Sub Command1769_Click()
Me.Refresh
If Len(Dir("file location" &
[Combo1199], vbDirectory)) = 0 Then
MkDir "file location" &
[Combo1199]
End If
I have replaced the name of the file location with 'file location' however I have checked and it is correct. The [Combo1199] is the name of a folder which is already present in the directory, and its date modified shows as being when the VBA code was run. The debug shows the problem as occurring on the If Len(... line
EDIT SOLVED: For some reason the DNS servers weren't set to be found automatically so I wasn't connected to the applicable license server.
Amongst other possible reasons, in my experience, run-time error 52 can arise when a path is valid but inaccessible, for example, a mapped network drive for which the user has insufficient read permissions, or which cannot be accessed due to the target being offline.
I would therefore suggest that you print the path represented by "file location" & [Combo1199] to the Immediate Window (view this using Ctrl+G in the VBA IDE) using:
Debug.Print "file location" & [Combo1199]
And then ensure that you can access this location 'manually' through File Explorer from the same PC, using the same user credentials that are active when the code runs.
I've been working with SharePoint 2010 with no problem using VBA and accessing the folders via a simple path
\root\site\folder , structure.
I've just had a new site created in SharePoint 2013, and using the same technique doesn't work.
I can add a network location in this format
https://server/sites/Shared Documents, and can open that OK with file explorer, but when I pick up that string from my vba using a filesystemobject, I just get path not found.
If I map a network drive letter, for that path, the code works OK, but the path isn't found if I use the full https://server etc.
My guess is that it's something to do with changing from http to https on the move to SharePoint 2013
Anyone come across this before?
The actual code runs in Access 2013 and generates a full list of all the files in all the subfolders, and the ONLY problem now is that the filesystemobject.getfolder cannot find the path https://server/sites/Shared Documents (but will if I map all that to drive W:)
Any clues or suggestions welcome.
Thanks
Just in case anyone else has this, in my case, SharePoint 2013 needs
"#SSL\DavWWWRoot" added to the path, just before the "\Sites"
I found this by close examination of the path created by the drive mapping.
My problem is several (Windows) computers run from different drive letters (C drive, D drive, etc…) and I need to determine the one which the program is running on to save a TXT file of the history and bookmarks and some other stuff that is collected from the web browser that I designed. Visual Basic and C# code would be useful (VB preferred).
Use the function designed to get you the Windows-defined special folders, like this (untested):
Dim dirBrowserData As String = IO.Path.Combine( _
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), _
"YourBrowserName")
Putting user data on the root of whatever drive you're on is not recommended and may not be possible depending on security settings, but the local (non-roaming) user data should almost always be fine, because that's literally what that Windows API is there for.
Ok, our current problem is the classical "trying to allow multiple users access onto one fe file (this is in runtime currently)" - This cannot be handled (at least in AC2007) and is best solved by installing a FE on each computer that is using it.
This poses another problem for us, we have many employees who we want to be able to have access to it, yet the program probably doesn't warrent our techs to push out updates of this file to each computer with their "patches" (plus there may be added costs to doing such for us).
We would really prefer the ability for users to open a link from our internal portal to the file as can be currently achieved. We are mulling over the possibility of pushing out 4 or 5 copies of the FE application on a shared folder and creating an Access program that would essentially check to see if a FE app is open say FE1 and if so it would open FE2 (and so on) then close the sharepoint linked database that did the checking so a new user could open that. This would allow multiple users access to the same BE information using the same FE program.... would this work? Any ideas of how to go about it?
Yes it works, the idea is to create a function that checks for the open file, if it finds its open it replies with an error, on the error you can move to the following database. Here is a sample code:
Option Explicit
Function FileLocked(strFileName As String) As Boolean
On Error Resume Next
Open strFileName For Binary Access Read Write Lock Read Write As #1
Close #1
If Err.Number = 0 Then
Application.FollowHyperlink "c:\MasterMAX.accdr"
DoCmd.CloseDatabase
End If
If Err.Number <> 0 Then
Application.FollowHyperlink "c:\MasterMAX2.accdr"
End If
End Function
Disclaimer: I don't know anything about SharePoint, so I can't say if my proposed solution is still viable when SharePoint is involved.
If your problem is just how to distribute the file to all machines, why don't you let your users start a batch file that copies the Access frontend from a network share to each machine and starts it?
We are doing something similar at work (without SharePoint, though), and I described our setup here:
How to automatically update MS-Access 2007 application
We have put the batch file on a network share as well. The users have just shortcuts on their desktops to the batch file on the network share, so it's easy to update the batch file as well.
Maybe you can do something similar (let the users run the batch file from SharePoint, which copies and starts the Access frontend).
I’m well aware of the Microsoft support base article stating that it’s not supported to automate office products UI less. It seems that Windows Server 2008 x64 and Excel 2007 enforce the given statement.
I’m running the following code in a NT Service (Local System account) OnStart method. All it does is Excel automation the way it’s working when you run the same code in a Console Application.
The provided code has two parts. The first part launches Excel, creates a new work book and saves it to the given filename. The second part launches a new instance of Excel and opens the given file. The open operation ends in this exception:
Service cannot be started. System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file 'c:\temp\test.xls'. There are several possible reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook.
Why was the automated excel able to launch and write files to disk but fails when it’s asked “just “ to open an existing file?
System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
// launch excel and create/save a new work book
Microsoft.Office.Interop.Excel.ApplicationClass excel = new Microsoft.Office.Interop.Excel.ApplicationClass();
excel.UserLibraryPath, excel.Interactive));
//
string filename = "c:\\temp\\test.xls";
if(System.IO.File.Exists(filename)) System.IO.File.Delete(filename);
//
excel.Workbooks.Add(System.Reflection.Missing.Value);
excel.Save(filename);
excel.Quit();
excel = null;
// lauch new instance of excel and open saved file
excel = new Microsoft.Office.Interop.Excel.ApplicationClass();
try
{
Microsoft.Office.Interop.Excel.Workbook book = excel.Workbooks.Open(filename,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
true,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value,
false,
false,
System.Reflection.Missing.Value,
false,
System.Reflection.Missing.Value,
System.Reflection.Missing.Value);
book.Close(false, System.Reflection.Missing.Value, System.Reflection.Missing.Value);
book = null;
}
finally
{
excel.Quit();
excel = null;
}
//
GC.Collect();
The solution is really simple. The msdn forum thread can be found here
To make a long story short I'm posting the solution here, credit goes to H Ogawa
This solution is ...
・Windows 2008 Server x64
Please make this folder.
C:\Windows\SysWOW64\config\systemprofile\Desktop
・Windows 2008 Server x86
Please make this folder.
C:\Windows\System32\config\systemprofile\Desktop
...instead of dcomcnfg.exe.
This operation took away office automation problems in my system.
A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.
It disappears from Windows2008, Windows2003 had the folder,
and I think it cause this error.
Also like stated in the source, you need to set the correct rights for the Desktop folder.
This worked for me on Windows 2008-64bits and Office 2010 32bits.
Create directory "C:\Windows\SysWOW64\config\systemprofile\Desktop " (for 64 bit Windows) or "C:\Windows\System32\config\systemprofile\Desktop " (for 32 bit Windows)
Assign user "Network Services (Service Réseau)" the following rights for the created folder:
Read & Execute, List folder contents, Read
John.
I've quite often found that calling Quit() isn't enough to release the resources. Try adding: -
System.Runtime.InteropServices.Marshal.ReleaseComObject(excel);
between the Quit() statement and setting it to null.
There are many more errors than the one mentioned that you'll need to work through in order to get Excel working on Windows Server 2007 64-bit. See the steps I worked out after working on this for two full days!
If you are using Apache, you might also need to follow these steps to get MS Word working properly (along with everything outlined in other answers):
Below is a screenshot showing the two dialogs you'll need to bring up:
For Apache:
Services->Apache->Right Click (Properties)->Log On Tab
MS Word:
Launch dcomcnfg.exe->Console Root->Component Services->Computers->My Computer->DCOM Config->Find Microsoft Application->Right Click(Properties)->Identity Tab
**if you can't find the MS Word, make sure you are launching the correct DCOM Config (64 bit vs 32 bit) depending on what version of Office you have installed.
There are two options here, you can set Apache to use Local System Account and check the checkbox to ALLOW desktop interaction. If you do this then you need to set the Identity for MS Word to Interactive User.
Otherwise, you need to set both to the same user (Ideally the user that is logged in) like shown in the picture.