I have program which get the word file from server and after editing it saved back to server . It was working and i was able to save files back to server but suddenly files are opening in Readonly mode . I have searched alot on google and have tried all options but it seems not working.Any ideas clues ??
If the file displays as read only in Word that means word thinks the file is readonly, which means its seen something to make it think that. Since word does not integrate with access control methods over webdav, that means it can only be that word has determined that the server does not support required operations for writing. This can be:
does not support uploading (ie PUT). Webdav reports this in the OPTIONS request, so please check for that
does not support locking (ie LOCK)
does support locking, and the file is locked. But this usually gives the user a specific warning
Locking comes into play in different ways depending on how you're connecting to the server (on windows you can either use a mapped drive or a network location), and the means of opening (either clicking a link in a web page which uses the sharepoint dll, or opening directly from a mapped drive, or opening from the file open dialog in MS office), and of course the application doing the opening (ie MS Office, Open Office, etc)
Depending on what combination of the above you're using locking might or might not be required to edit.
Webdav indicates locking support in the following ways
- the supported levels header
- MS-Author-VIA header, which should return "webdav"
- the presence of LOCK in the OPTIONS response.
So you might need to check for the presense of those, probably by using wireshark or similar.
Related
i have a shared access application, i created an accde file for 32-bit machine, when user open the application he/she getting a security warning
is there any way to disable this message from appearing to the users
thank you
You have to set their computer to be a trusted source. In order to get around this issue, you will need to create a Digital Certificate. Digital Certificates are good only on the computer they are created on, so if this database will be used on multiple computers then each one will have to create a Digital Certificate.
To do this, you will need to perform the following tasks:
Click on Start -> All Programs -> Microsoft Office -> Microsoft
Office Tools -> Digital Certificate For VBA Projects (If you don’t
have this, you will need to contact your IT Dept.)
Enter a Certificate Name. Make it obvious like MyProgramName and Click OK
Open the Access database which contains the security warning you want to bypass
Go into the Design View of any Module
Click on Tools -> Digital Signature
Choose your Digital Certificate you created in Step 2
Save and close the database
Re-Open the database. You will now be prompted with a different Security Warning that states the file has been digitally signed.
Check off the “Always trust files from this publisher…” box and click the Open button
All subsequent times you enter this database, you will not be prompted with a security warning.
Note - I wrote the above for our company based on Office 2003. If you're using a more recent version, the instructions may vary somewhat.
other way is following:
click on file and then options
click on trust center and then trust center settings on the right
then click on trusted locations and add new location
browse for the location and save.
that's it.. done.. now no more warnings..
That is a standard warning to indicate the file you are opening has web links and macros.
If you trust the file, just say OK or “Allow”
You can control if this message is displayed: Office button > Excel Options button > Trust Center > Trust Center Settings button (I have no idea why they have this extra button, DUMB DESIGN! )
More Information can be found here
I have an Access database that processes other Access databases. I get OP's error when connecting to one of the other Access databases. To fix the issues, I opened the other Access database and clicked Enabled Content. Then, the Access database is trusted and OP's error doesn't occur when connecting to that Access database from another Access database.
You can create a registry key that will add the directory as a trusted location and will not show the warning anymore. What's nice about this method is that you can easily automate this to happen on the computers where you deploy your app. See method #2 or #3 in this blog: http://www.accessrepairnrecovery.com/blog/fix-microsoft-access-security-notice
And in case the blogs ever gets removed, here is the important bits:
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\Location20] “Path”=”C:\Database\”
“Description”=”My Database location”
Explanation about the key:
– The number “14.0” is the version of MS Office. You can change the numbers that represent the version you are executing.
– The “Location20” is a unique name that you assign. 20 can be any number that is not previously used. Other programs include default MS Access wizards, already have used other numbers. But if you want to make more than one path as trusted location, then each location must end up with different number.
– The “C:\Database\” is the physical path that you want to set to be as Trusted Location. You can place any path that you choose here.
By copy and pasting the above coding into a text file and save it with a name such as RemoveSecurityWarning.reg, you can then run the file into your PC’s registry just by making double click on the file.
The best way is to add the location of the document or the document itself to the Trusted Locations in Registry (if you use only Access runtime on client machines, there is no way to add it through the Office application, like you would do in Excel).
Here is the answer:
Adding Trusted Location to Access Run Time
You would need to create a new Location key and add the necessary Path (and Description) strings inside with the appropriate location of your file. This way the nag dialog will be gone and you won't need to worry about certificates.
Shared may mean it is located on a network share. It is not advisable to add a network location to the Trusted locations and you would need to set the additional flag AllowNetworkLocations to 1. I would advise you to copy the Access modules to the user computers, which would also make things better with the speed I believe.
If anybody else have this problem, it happened to me, with a shared file on a network environment, and the simplest solution was to install Microsoft Office service pack 2, even better is having automatic updates for Office turned on. You can find it here.
I came by this page and was thinking about the best method to distribute my VbaProject.OTM file (located into %appdata%\Microsoft\Outlook\) to a bunch of ~30 users at my office. Is it better to simply copy/paste the OTM file onto the network and then copy/paste it back to all users' computers (manually or with a .bat) OR would it be better to use the method described in the link above to generate a OPS file and import it back with Proflwiz.exe? What's the difference?
We are all on Microsoft Office Outlook 2003 actually, we might upgrade to 2007 one day but still years from now.
Finally came up with some elements to deploy a Outlook VBA Project. There are a lot of ways to do this, but the easiest way to do so without installing anything and keeping the same methodology would be to run a OTM file directly from a server. I found out that the process outlook.exe has a parameter altvba that allows to specify another path to run the OTM file from. Here is en example:
outlook.exe /altvba "\\myServer\myFolder\myFile.otm"
This allows me to update only one file to get all computers updated. Obviously, if the file is big and the server's ping is on the high side, it may delay the launch of Outlook. The other problem with this method is that everybody will have to shut down Office if you want to update the OTM file on the server (and if you do work in an office where everyone uses Outlook, you do know that it is impossible to get everyone to shut it down at the same time, except if you code a macro to do so eventually). To prevent both those problems, I could setup a batch file to copy the server OTM file clientside everytime there is a new version (just have to check the NTFS last-modify attribute). This way, Outlook will boot with a local file, the batch file take 2-3 seconds to copy the file if needed (or will launch Outlook instantaneously) and there will be no problem updating the OTM file on the server. Users will have to start Outlook with the batch file (or with the slightly different outlook.exe path with the altvba parameter, so either way they need a different shortcut/file to start off the first time). One other advantage of the altvba is that it's still easy for the user to run Outlook without it (to see if the VBA is problematic or not in case Outlook is sluggish) and the file will remain unchanged after a Outlook reinitialization.
Others solutions include a COM complement that can be developed in a lot on languages including VB6 (no conversion needed from VBA). There is also a bunch of tools included into Microsoft Office XP Developer that could help getting the job done (not free however, especially if you need the most up-to-date version).
Is there a way (via shell extension or registry setting) to tell Windows Explorer that it shouldn't read files in the folder being shown in order to extract metadata or create thumbnails?
The problem is that when the user navigates to the folder, Windows Explorer attempts to read all files in the folder and extract certain metadata from them. If the medium is slow, this takes ages and causes unnecessary load on the file system. This is especially true in case of thumbnails, when the whole graphic file is read.
I am looking for ways to do this (restrict Explorer) in code, so "don't use Thumbnail mode" is not an acceptable answer :).
Upd: per-user settings won't work unfortunately cause we as a disk provider can deal only with our own disk (and the user might want to have separate settings for regular disks and virtual disks). I believe there must be some way to "explain" the OS that the drive is slow.
Maybe there's some IRP on driver level that we need to handle to tell the OS that the medium is slow?
Is there a way (via shell extension or
registry setting) to tell Windows
Explorer that it shouldn't read files
in the folder being shown in order to
extract metadata or create thumbnails?
Not that I know off, but depending on the priorities regarding the use case details you outlined there might be two options still to approximate the desired result:
Via group policy
Note that this essential expands/details the network folder related aspect of Freds answer, which you dismissed in your update; however, you claim to be able to deploy shell extensions or registry settings and the following two group policies simply execute the latter by administrative means:
User Configuration -> Administrative Templates -> Windows Components -> Windows Explorer:
Turn off the display of thumbnails and only display icons **on network folders**
Turns off the caching of thumbnails in hidden thumbs.db files.
This boils down to the following registry settings:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
"DisableThumbnailsOnNetworkFolders"=dword:00000001
"DisableThumbsDBOnNetworkFolders"=dword:00000001
Of course this is still not per folder, but at least limited to network folders and ignores regular disks and virtual disks.
Via hackish workaround
Given your statement we as disk provider can deal only with our own disk there might be a hackish workaround, though I'm afraid it lacks the last mile (untested by myself).
Starting from Chris W. Reas own answer to How can I suppress those annoying Thumbs.db files in Windows Vista and Windows 7?:
Also worth knowing: In Vista and Windows 7, Thumbs.db applies to network folders only. For local folders, Vista and Windows 7 instead save thumbnail cache information to a database in a local folder at "%userprofile%\AppData\Local\Microsoft\Windows\Explorer"
Continuing from there, Wil claims the following potentially clever solution to work on a per folder basis:
Go to the drive and create a file called thumbs.db (in notepad or anything), then change the permissions on the file for everyone (including SYSTEM) to deny all.
Unfortunately, aside from the automation requirements to create the dummy thumbs.db in each folder, the outcome depends on how Explorer will react on the inaccessible file - because caching is optional as per group policy, it might as well display thumbnails without caching them, making the bandwidth issue even worse in turn ...
Good luck!
I'm not sure if you can disable thumbnail generation/display for certain folders but this article talks about a script which could quickly disable it via context menu.
The script modifies a value in the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\. I suppose you could find something similar in that key for the other metadata. ShowInfoTip sounds promising. There might be relevant information in other nearby keys.
This may be a complete non-answer depending on your needs, but how about storing the files without file extensions that the OS wants to make thumbnails of? Call it file.jpg.abc and it won't be reading thumbnails, for sure.
I've got an Access 2007 database that I developed which connects to SQL Server for the actual data storage. I used the Package Solution Wizard to create a distributable installer which included access runtime (with an ACCDE file) which I went around and installed on 15 or so PCs. Anyway, my question is, what is the best way to distribute updates to this database? Right now I'd need to go around and remove and reinstall. That's not a problem... I was just wondering if there was another way.
I've tried leaving the front end on a network share but it seems that most people suggest storing the front-end on the local machine, which makes sense. The problems I've run into when I leave it on a network share (at least with Access 2003 mdbs) is that I find myself needing to compact and repair often and I also have to kill the open sessions (user's who have the file open) when upgrading. I would imagine it could also hypothetically create an unnecessary bottleneck if the user was not on the local network.
Automating front-end distribution is trivial. It's a problem that has been solved repeatedly. Tony Toews's http://autofeupdater.com is one such solution that is extremely easy to implement and completely transparent to the end user.
We developed a vbscript 'launcher' for our access apps. That is what is linked to on the start menu of user's pcs and it does the following.
It checks a version.txt file located on a network share to see whether it contains different text to a locally stored copy
If the text is different it copies the access mdb and the new version.txt to the user's hard drive.
Finally it runs the mdb in access
In order to distribute an update to the user's pc all that is required is to change the text in version.txt on the network share.
Perhaps you can implement something similar to this
Make a batch file on the server (network drive).
Create a shortcut link to that batch file.
Copy the shortcut to User's Desktop.
When user double-clicks on shortcut, it will copy a fresh copy from network to local.
Replace old database.adp on the server drive when you update a new version.
Each user gets a copy of database.adp on their machine.
Remove Security warning when opening file from network share is here.
Batch File
#ECHO OFF
REM copy from network drive to local
xcopy "Your_Network_Drive\database.adp" "C:\User\database.adp" /Y /R /F
REM call your database file - Access 2007
"C:\Program Files\Microsoft Office\Office12\MSAccess.EXE" "C:\User\database.adp"
This is a very old post and I used the autofeupdater until it stopped working so I wrote one of my own and it has evolved over the last few years into something that I have used with many clients. It's so simple to use and there is no interface. Just an EXE and a very simple config file.
Please check it out here. I can also help with custom solutions if none of the configurations work for your needs. http://www.dafran.ca/MS-Access-Front-End-Loader.aspx
After trying all of the solutions above (not exactly these solutions but these are the common suggestions in the Access community), I developed a system entirely within Access using VBA that allows an admin DB to create and publish objects to client DBs without the need for user intervention or management of multiple DB files.
This approach has several benefits:
1. It simplifies the development process by having a dedicated environment (admin DB) for development and testing totally separate from the client DBs.
2. It simplifies the update/distribution process by allowing a developer to push out updates in real time that client DBs can implement in the background, without involving users. Can also allow devs to roll back to previous versions if desired.
3. It could be used as a kind of change management system within Access for developers who want to commit multiple changes to objects and modules and retain past changes.
4. It allows for easier user access control by allowing an admin to easily assign certain objects to specific users/roles without needing to maintain multiple versions of the DB.
I will hopefully post the code to GitHub soon, I just have to get clearance from my workplace to release it. I will edit this post to include the link when I have.
We have usually kept the Access front ends on network drives, and just put up with the need to compact and repair on a regular basis. You will probably find you need to do that even when they are installed locally, anyway.
If you must have it installed locally, there are various tools which will enable you to "push out" software updates, and the guys over on ServerFault would have more information on those. Assuming such tools aren't available, the only other option I can think of is to write a small loader program that checks the local .MDB against a master copy on the server, and re-copies it across if they are different, before then launching the MDB.
While opening any MS Access database, a security warning appears saying that the file can be harmful to the computer. However, is there a way to remove this message. Or should it remain a necessary evil
You can probably sign your program. I don't know for sure. Read this article and see if the same principle applies.
If you lower the security settings in your Access options it will go away I believe. Of course those settings are set where they are for a reason.
Here are some more notes on certification and security.
Certification, including self-certification:
http://office.microsoft.com/en-us/access/HP010397921033.aspx
General information on security principals for Office code and macro security: http://office.microsoft.com/en-us/ork2003/CH011480831033.aspx
Trusted location defaults for Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403181033.aspx?pid=CH011480851033
Macro security in Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403071033.aspx?pid=CH011480831033
You can eliminate the security warning at the startup of a ms-access project by putting the access project in a Trusted Location. Or Better yet, make your own Trusted Location.
I recommend creating a folder in the System (C) drive with the name of your project. For example, we could call the folder Database (Path: C:\Database)
Then enter this path as a registry key like this:
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted
Locations\Location20] "Path"="C:\Database" "Description"="Access
Project location"
Now lets explain a few things about what this key did:
The number "14.0" is the version of MS Office. You can simply change that to the number that represents the version you are running.
The "Location20" is a unique name that we assigned. The 20 can be any number that is not already used. Other programs, including default MS Access wizards, already may have used other numbers. Or if you want to make more then one path as a trusted location, then each location must end with a different number.
The "C:\Database\" actually is the physical path that you want to set to be a Trusted Location. You can put any path that you choose here. I am not sure why it uses double \, but I just copied the example of how the previous keys were set up and this seemed to work best.
The Description is not needed, but obviously any description can be used.
For more details on how to make Trusted Locations work for your MS Access project, read our detailed explanation here: http://blog.ideaz.net/2013/12/how-to-remove-microsoft-access-security.html
Here's my notes from a similar, internal issue with Access 2003 a few years back:
Okay, so here's (evidently) the deal.
The network server was not in the Trusted Zone. Starting, IIRC, with SP2, this causes a Open/Save/Warning box when opening a file. By default, UNC paths are supposed to be in the Trusted Zone. I'm not sure why it wasn't, but here's the fix: Add server.dns and server to Internet Options->Security Zones->Local Intranet.
Unsafe Expressions Are Not Blocked. This is some ridiculously overcomplicated Access security model (Google for unsafe expressions and Access Sandbox Mode for more). Basically, Access (starting with 2003 and/or Jet 4.0 SP8, I think) warns you if a registry key is not set to disallow "unsafe expressions". The fix: Set HKLM\Software\Microsoft\Jet\4.0\Engines\SandBoxMode to 3, which blocks "unsafe expressions" for anything using Jet. This has to be done by an Administrator. Alternatively, I think that answering "Yes" to the Block Unsafe Expressions prompt as Administrator sets that key for you.
This file may not be safe to open. This is an easy one, and follows the whole macro security model in Office. Just set the Tools->Macro->Security (don't look in the Tools->Security menu...that'd be too obvious) to Low.
BTW, I still have no idea what an "unsafe expression" is - nor why it continually asks to upgrade to Jet 4.0 SP8 when it already has been (I verified that it was updated by checking the file versions). But with those changes, it no longer asks anything when starting up. --MB
In Control Panel, click 'Internet Options'.
In the 'Internet Properties' popup, select the 'Security' tab.
Select 'Local Intranet' zone.
Click 'Sites' button.
In the 'Local Intranet' popup, clear the "Automatically detect..." checkbox and set the following checkboxes:
"Include all local (Intranet) sites not listed in other zones"
"Include all network paths (UNCs)"
'OK'.
'OK'.
Now all Access dbs anywhere on your Intranet or any referenced by a UNC will open immediately without warning. You assess the convenience/security tradeoff.