In Sharepoint Foundation 2013 (and from what I've read, Sharepoint 2013 also), there is currently a bug that, with "check out" features disabled, still allows Adobe Acrobat to flag a file as "checked out". Worse, Adobe has this as the default (the fix I found for this separate problem is here: http://community.spiceworks.com/how_to/show/2414-disabling-sharepoint-integration-in-adobe-acrobat-and-reader-x-version-10-1 ). I have been through the system top to bottom, and looked around the web, finding others in this conundrum, and there is no current way to fix that, and the only interface control for un-checking-out a file for a user is nonfunctional because it's a file that should not have been able to be checked out.
Up until now, at least as recently as a couple weeks ago, I had been able to edit the database to clear this by nulling out the fields CheckoutUserId, CheckoutDate, and CheckoutExpires in the Sharepoint-generated table WSS_Content_(gibberish).dbo.AllDocs but doing so now has no effect whatsoever.
Is there a new or additional location in the database that needs to be edited to remove these manually?
The prior fix mentioned above (nulling the fields CheckoutUserID, CheckoutDate, and CheckoutExpires in WSS_Content_(gibberish)) allows the files to be cut and pasted from the "Explorer view" and then cut and pasted back in, removing the "checked out" status. It has the downside of changing the edit date, time and user.
Related
I have an Microsoft Access 2010 database application with split front end and backend which has started to behave oddly, and I've exhausted all the options I know for investigating and resolving the problem.
32-bit Access 2010 running on Windows 8.1... I have both Access 2010 and Access 2013 installed, but the problem also manifests itself on a Windows 8.1 system with a completely fresh install of Access 2010 and no Office 2013 present. The issue also exists if the application is run using Access 2010 Runtime. The front-end is running on my hard disk, not in a Dropbox or similar environment. The back-end is in Dropbox.
There are a couple of third-party elements in the application -- references are as shown -- example 1 on the system with both Access 2010 and 2013 present, example 2 on the system with just Access 2010 present.
There hasn't been a software update to the Treeview control since December 2013. I've checked that the versions of the third-party controls I'm using are compatible with Windows 8.1.
Symptoms:
The application (an unreleased development version) initially works perfectly, but if closed and reopened, one specific operation (right-click on a third party treeview ActiveX control on the main form) misbehaves -- the right-click event is triggered multiple times instead of just once (the number of times is unpredictable). There are two treeviews on the main form with identical settings (populated dynamically with different data sets). One treeview behaves, one doesn't. Even if I remove all code from the right-click event, it fires twice.
This main form configuration and code hasn't been changed in over one year, not has the treeview config or code. I don't use Compact on Close. The application isn't logging any errors.
What I've tried:
If I restore a previous version of the application, it works... and when reopened, doesn't work. (I've tried this with several previous versions of the database.)
I've tried importing a copy of the main form from an old working version of the database -- same problem.
I've tried deleting the malfunctioning treeview and creating a new one (copying the one that is working) -- same problem.
I've tried creating a new blank database and importing all the objects from the old one. Once I've restored the references manually, the same problem.
I've reviewed all the possibilities mentioned in Can't eliminate Access corruption -- one commonality I have with this question is that I've (last three months) started using the VBA Implements keyword, but I hadn't made any changes to this code immediately before the problem showed up, and neither the main form nor the treeview control utilise it.
I've emailed the support team for the treeview control, but they haven't anything to suggest that I haven't already tried.
I've repaired the installation of both Access 2010 and Office 365 in case the references were somehow messed up.
I've un-installed Office 365 and Access 2010, rebooted the machine and reinstalled Access 2010. The references are all Office 14 references and the problem still exists (in a compiled accde). As soon as I reinstall Office 365, the references become mixed 14 and 15. (This is also true for the working version which is two years old).
What I haven't tried yet:
Rolling back a two months' worth of Windows updates to see if it's a Windows issue (this system has only been in use since early September, so this wouldn't be hugely onerous to try).
Rolling back to a version of the app from December 2012 (the last production release) which doesn't seem to have suffered the corruption and manually reapply almost two years worth of development changes. This would be a mega undertaking....
Are there any other options for investigation or resolution that I can try?
Edited to add: What finally worked
I created a new empty database, imported everything from the old database except the main form, which I recreated from scratch to look identical and have the same code as the old one... And the problem has gone away. It not very satisfactory as a resolution, but it seems to confirm that there was a corruption somewhere.
One of the best ways to remove corruption in an Access database is to save the forms and reports to text using the undocumented SaveAsText function, delete the form and report objects, close the database, use the undocumented /decompile switch to decompile the database, compact/repair the database, then re-import all the objects using the undocumented LoadFromText function.
Usually the Access databases corruptions affect the VBA modules, less likely the table data. So hopefully you should be able to copy the data to a blank database, get the VBA code from a older backup (since the last source code update) and merging the two together. It should work!
It won't stay fixed unless you disable updates. And you can't disable updates because you will be compromising security.
I am running a Citrix-driven environment, and I have a vital piece of software that creates a PDF repository of all reports as they run. The problem I have is that the users' printers must populate into the environment (Not just the default printers- ALL of them), and a number of the computers have Acrobat 9 or X on them. The software that creates the reports REQUIRES that the Rely On System Fonts is turned off, but some users have it turned on when it comes to the PDF printer on their computers. Sometimes, when user x goes to create a report, it will grab the printer from user y's session that may not have the option properly unset- Then user x's irreplaceable report is lost. The application is a Dexterity application, and I don't have access to the source. Is there a way, in Citrix or in AD, to script this one option to be unset properly? Any idea if there is a registry key or some kind of hook I can activate with a powershell script to fix this headache? I appreciate any help.
I have been researching for weeks to figure this out for myself, and I was looking for one more answer and found your question. To fix your problem I was able to find that the registry key found here:
[HKEY_CURRENT_USER\Printers\DevModePerUser]
Contains all of the current printer properties. If you export it, you can run a script to add the reg key during login. Just make sure that you restart the spooler after words, just to make sure that the changes apply. Also the settings will only apply to the printer with the same name, so you have to have a different reg key for each different printer name, if you have several. I just esported the key after I had changed the printer settings to how I liked them, and then edit the .reg file to remove any data about other installed printers to make sure that the .reg file wouldn't affect any other printers.
Apparently, this problem is a common problem. Microsoft has acknowledged that the PDF creation issue I am trying to avoid is an issue in GP, starting in (Think it was version) 7. The Microsoft-recommended workaround is to open the PDF Printer properties and uncheck the Use System Fonts box. Adobe does not support this configuration, so they will not provide a clear way to implement it at a network level with clients in many locations and 4 different major versions of Acrobat. The closest I came was a post that identified an incredibly long string I have to hexedit that seems to change in specific minor versions of Acrobat. Way to go M$ and Adobe. So, in other words, no support on major product lines from two major companies. I have nowhere else to go at this point. If anyone else has a solution to this problem, I'd love to hear it. Thanks!
I have a SharePoint 2010 document library with >7000 xml documents created from infopath forms(Infopath 2007). Now i would like to promote few fields in the form to the SharePoint document library. I could do this only for documents created from the upgraded form, but not for all previously created documents. Although re submitting of old forms will work,It is not possible for me to update all 7000 records to promote the values to the column. Is there a much easier solution, considering the fact that this changes need to be implemented on a production environment too.
Note:The promoted columns will be used to generate graphical report. Any solution acceptable.
I've been through this before, and there's no good answer. If I understand correctly, you have existing InfoPath forms in a doc library, and you now want to promote fields to the document library, but you don't want to open each form one by one, correct?
Note, you most likely don't have to open then re-submit each form, you just have to open the form, and close it. Once you do that, the promoted fields will them show up.
So... what I've done before is this: First, get notepad++ (this allows you to open multiple files in tabs). Secondly, access the the doc library via WebDav (that is, go to the library in SharePoint, then go to the Library tab, and click Open with Explorer). Thirdly, open a large batch of files at once using notepad++ (select files, right-click, open with notepad++). It will take a moment for all the files to load in notepad++ in tabs. Once they are all open in notepad++, hit ctrl-w as fast as you can (which closes each file). Rinse and repeat.
It's not pretty, and I'm sure there's a better way to do this (programatically, perhaps), but this should work. At least you won't have to open each form one by one.
You can do this by relinking the document by powershell or through advanced settings.
I'm pulling my hair out because I've run into the following problem with one of my clients:
My program uses extensive VBA automation in Word. Macros are saved in a specific Word template that is attached to each document. Some of the macros save the current document to a temporary folder under [User]/AppData/Roaming/... for further processing.
The client is using Win7 with Office2007 (Student edition). On the computer in question I keep getting an error with something like "No permission to save the file" (can't give exact error message because I've translated it from my language to English)
This happens when the macro tries to "SaveAs" the document.
The strange thing is that it happens only 8 out of 10 times - and not all the time. There are no special permissions set for the temporary folder I'm trying to save to.
I've tried changing Word security settings, tried adding the folder to the trusted folders list, tried using a different folder - to no avail.
The client's computer has Norton Antivirus (or Internet Security, I dunno) installed but temporary disabling it didn't solve the problem. (I know I should only be sure after a full uninstall but I can't do that on the client's comp)
Any help is appreciated!
Update: I've since found the exact error message in English: "Word cannot complete the save due to a file permission error."
I'm now looking on the web for similar forum posts but if you guys know something, please let me know. Thanks!
Is an antivirus or similar program running? On my development computers many similar problems went away when I changed from (vendor "X" security bundle) to ESET.
A friend asked for my help putting together an Access database for a small department at a university. It tracks medical info on some animals. The problem is that to make the application easy enough to use, we had to write some VBA code to glue different forms together. When we open the database (or a new, updated version of the database), we get the little VBA Macro Trust thingie, and we're having a hard time figuring out how to get rid of that warning. I'm an open-source developer and my organization's sysadmin, so it's usually not a problem for me to sign rpm packages with the CA Cert I maintain...
My friend's department uses Windows PCs with Novell, but their computer support department has stated that they don't provide any support for user-created applications (i.e. providing a certificate signed by the departmental CA) nor will they provide administrator access to the computers so that we can change the trust settings. They also don't have the skills or expertise to code the application for the users. (Thanks, chaps, mighty helpful.)
Additionally, in our entire University, users are explicitly instructed not to ever, ever click a 'yes, I trust this' button. Re-educating users for the sake of this little access database that she's put together is a problem, since about 20 people will be using it to look up information.
Since I'm helping her, my inclination would be to do it in C# with a embedded database file stored on a shared drive, but that also falls under "user created applications" and I wouldn't be able to run an installer since no one has administrative rights.
Is there any way to work around the need to bypass the trust setting for macros every time someone opens this file? I thought that if we didn't use macros at all and just used VBA it would work, but that's apparently not the case.
You might find some help on:
http://msdn.microsoft.com/en-us/library/bb421308.aspx#OfficeAccess2007SecurityConsiderations_EnablingExecutableContentDatabases
Specifically:
Embedded Access Macros
In Office Access 2007, you can now
embed macros in form events like VBA
instead of saving them in the Macro
collection as separate entities. This
makes them more portable because you
can copy and paste a control with an
embedded macro, and the macro remains
with the control. In many cases, an
embedded macro for opening a report is
sufficient instead of a short sequence
of VBA for the same task. You can see
many samples of these embedded macros
in the Featured Online Database
Templates in the Getting Started with
Access pane that appears if you open
Access 2007 without selecting a
database. Because most Access macros
are not executable content, they are
an important tool when you have to
make your databases work in all
circumstances.
You're clearly on the right track since you mention the TRUST CENTER. I don't use A2007, but 2 minutes of Googling turned up these two articles:
View my options and settings in the Trust Center
Create, remove, or change a trusted location for your files
The instructions given there for Access are:
Click the Microsoft Office Button , and then click Access Options.
Click Trust Center, click Trust Center Settings, and then click Trusted Locations.
If you want to create a trusted location that is not local to your computer, select the Allow trusted locations on my network (not recommended) check box.
Click Add new location.
In the Path box, type the name of the folder that you want to use as a trusted location, or click Browse to locate the folder.
If you want to include subfolders as trusted locations, select the Subfolders of this location are also trusted check box.
In the Description box, type what you want to describe the purpose of the trusted location.
Click OK.
Looks to me like that should take care of your problems, though it has to be done on each users computer.