I have SQL Developer on machine. Once while exporting data from database to my local drive, It prompted me to ask whether " you would like to allow the local drive to be writable or not". I accidentally clicked No. From then, I am not able to export any file from database to my local drive. Every time I get an error saying "Save as Target :D is not writable". I couldnt find any solution in the preferences section nor over the internet. I am accessing SQL developer via citrix. I have cleared cache, removed tmp files. Nothing helped. Is anybody facing the same issue? Any idea how to clear defaults? I use Windows 7 environment.
Even I faced this issue and googled but no luck. So, I started trying multiple options. Below one worked (exclude the double quotes as slash is lost while posting this update)
\\Client\C$\Test.txt
Example : \\Client\C$\Data\Test.txt
Related
I ended up corrupting my database to where every time I attempt to open it, I get error 3022, "changes you requested to the table were not successful because they would create duplicate values in the index."
Recovery of the file does not seem possible and my previous back up is a month ago. I have been able to extract everything but the Modules, which is what I need to recover the most. None of the standard ways I have found work because they require the ability to open the database (For example, trying to set it as a VBA reference still give the same error.)
Is there any way to get the modules or code out of the file without opening it?
Edit:
Was finally able to get access to the file. Using DBEngine.CompactDatabase it was able to do a compact and repair. The issue has boiled down to the "MSysAccessStorage" table is corrupt, and says "Id is not an index in this table". I know have access to everything, except the modules, which I can't open without the MSysAccessStorage working.
I'm going to keep poking at it but I'm not sure what options I have for fixing a system table. Any ideas would be helpful.
Unfortunately, the Visual Basic for Applications project has been corrupted. The original database doesn't even have any VBProjects when listing a count. I'm going to call this one a lost cause. Thanks everyone that tried to help.
I know that similar topics have been already raised, but maybe there are some latest news or ideas?
I want to migrate Datazen users/sources/dashboards etc. to another server (production one) in a smooth way. I was trying to do that via backup/restore, but then I couldn't access the control panel on the target server. I received an error
401 unauthorized access.
Maybe I should change something in logs/config files on the destination server?
Any ideas? I would be grateful for any help!
I dont think there is a way to do this out of the box. However, the files are quite simple XML, so can be pointed at a different server if you know PowerShell (and work out the correct values from the server).
You will have to re-point the GUID, ServerGUID and ServerURI within the sources.xml file and then rezip (as .datazen). Providing you have your hubs set up the same, Datazen will then believe the file belongs to your prod environment and you will be able to publish
I have an MS Access split database and I'm trying to get it to work with the backend on a new, more secure drive on our network. I've used a UNC path for the backend location.
This database has been running without problem on another drive which is totally public to everyone in the company (~4k people, not secure) for about a year. We have a generic account for users to access the database throughout our factory and haven't encountered this problem before I tried to switch it to the new drive. I've contacted our IT department and they've given myself and all my user's accounts read/write access to the drive, but only I can run it.
Other user accounts get these problems...
All of my forms with objects bound to a table immediately throw a runtime error before even getting to Form_Load.
My userforms will run DLookup functions and execute message boxes but throw a runtime error when they go to execute a query.
I've tried using an 'On Error goto' to try and actually find the problem but it throws a runtime error before that.
I can't think at all what the problem might be. IT have told me I have the same permissions as the other users. Any suggestions on what to do?
In the front end of your DB you may have to change the path which links to the tables. The tables are in the back end of the database, which you have now moved and therefore changed the filepath. the frontend wont find them. You can delete the table links in the front end then use External data > import and Link > Access. In order to re-link the tables using their new filepath. You would then need to redistribute your frontend to the users.
I'm not sure if you have already done this, however, you haven't suggested so in your question. hope this helps, apologies if it was helpless.
I hope you have found an answer to this. I wanted to answer as well, because I had the exact same problem yesterday. It turned out that the location was referring other users back to the folder's shortcut name versus it's full length name (it is called the W drive on my computer and the K drive on theirs). I solved the issue by spelling out the name in full.
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.
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.