Failed to update database becase the database is read only - winforms

I have created a winform application and programmatically trying to attach the database when an application runs first time. Unfortunately in windows 7 i always got an error. Please view the screenshot below it tells the whole story. Now my question is that how can i get rid from this error, is there any way to automatically give required rights on the folder where the application installs?. I want to permanently resolve this error and need smooth attachment. Anyone please help.
Please view the error below. Thanks in advance

Try ALTER DATABASE MyDatabaseName SET READ_WRITE
More informations here on This forum
Edit
This was asked by someone else

If you put your database in your own subdirectory of the directory returned by Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData then the user will have read/write access to it.
See Environment.SpecialFolder Enumeration to determine if a different location would be more suitable, e.g. ApplicationData if you need it to roam or CommonApplicationData if you need all users of the computer to use it.
Edit: I found a slightly more extensive version of this answer: Where Should I Store my Data and Configuration Files if I Target Multiple OS Versions?, please also see the articles it links to.

I know this answer is somehow late, but I believe people always face the same problems so my case is worth to be shared.
tl;dr = Change the permission of deployed files manually or using icacls command.
Actually I use InstallForge for packing and deploying my application(s).
No matter what setup creator is used, when the application is installed to a non-system folder ( e.g. D:\ ) the program works perfectly and the database is readable/writable.
Whereas when the application is installed in [Program Files] folder or [Program Files (X86)] folder, Windows takes a preventive security measurement and sets file permission to be only [Read] and [Read & Execute].
I think Windows Vista and later versions of Windows have this behavior.
You can check that by right-clicking the installed file and going to properties then Security tab.
The files I installed on D:\ had Full-Control permission while, as I mentioned, the ones on C:\ had only Read & Execute permissions.
You won't notice the difference when you install a normal program on C:\ because you might not be writing data on a file or a database. But in case of database deployment, the file has to be writable.
Finally, the solution for this case was telling InstallForge to change file permissions at the end of the installation using icacls commands :
icacls "C:\MyApp\MyDB.mdf" /Grant Everyone:F
icacls "C:\MyApp\MyDB_log.ldf" /Grant Everyone:F
In my case, it is okay to give everyone full-control on the database files, but you might need a customized solution for your case so please refer to :
http://ss64.com/nt/icacls.html
You can tell your setup creator to run those commands, or you can put them together in a batch file and run it after the installation.

Related

How to write files in C:\Windows\System32 with full permissions

Iam working on POS software using winforms. Iam trying to programmatically writing XML file (which contain some encrypted information about software serial number) to C:\Windows\System32 directory. But when i write i get an error Access denied.
Can anyone please explain how can i write this file with full permissions in this directory in windows 7 as well as in windows XP???
Any other suggestion or better way to do this will also be welcome.
Thanks in advance.
You'll need to be an administrator on the machine to write to the Windows directory. In addition, on Vista and later, your process will need to be "elevated" (otherwise known as Run As Administrator). You can configure this on your application's property sheet, as discussed here, or with a bit more work, do it programmatically.
It's bad practice to write to that directory, though, notwithstanding all the (misguided) software that does that. Save your files somewhere else. %appdata% or %localappdata% (directories specifically meant for application data) are good choices.

Batch file not working when running in the background - issue with substituted drive

I'll try to keep this short, without all the details of this batch file procedure.
OS: Windows XP
Action: Scheduled Task (background, I can't find a way to run it in the foreground)
Problem: files not created on mapped drive. When the batch file is ran directly, it works.
It does the following (or at least tries to):
clean a directory: works
create executables based on a substituted location
We use the following to map a local folder to the K: drive:
subst K: /D
subst K: D:\Development\SVN
The executables are built from source code that is located on (for example) K:\Sources to K:\Executables.
This fails, for a reason I did not yet discover. As mentioned above, if the batch file is ran directly it doesn't fail. If I substitute K:\ by C:\Development\SVN the issues seem to be resolved but still, this doesn't solve the fact that I can't run it when using K:.
I hope anyone here has an idea, I tried Googling for a long time + scanning SO but to no avail.
Thanks in advance!
substed drives are local to session, and your scheduled task is run in another session then your login session.
It seems to be possible to schedule task for user login session with schtasks.exe command line, but then the task runs only if the user is logged in. It might not be what you want, so using a full non-substed path might be the best solution after all.

Database errors in Quantum Grid demos in Delphi XE Professional

Whenever I open one of the Quantum Grid demos in Delphi XE Pro (on Windows 7 32-bit), the following error is displayed for every table (I think) in the project:
error message http://www.tranglos.com/img/qgerror.png
The message is:
Network initialization failed.
File or directory does not exist.
File: C:\PDOXUSRS.NET
Permission denied.
Directory: C:\.
I understand permission issues writing to c:\, but the result is that while I can build and run the demo projects, no data is displayed, which makes the demos rather useless. And what kind of database writes its configuration to c:\ directory in the 21st century anyway? :) (Yes, I know very little about Paradox databases, but I won't ever be using one either. I just want to learn how to use the grid.)
Using BDE Administrator I've tried changing the Paradox "NET DIR" value to a folder with write permissions on the C drive. Result: now the database tables cannot find their data:
Path not found.
File: C:..\..\Data\GENRES.DB.
...and the unhelpfully truncated path gives no indication where the files are expected to be.
Is there a way to work around the problem so that the demos can load their sample data correctly?
Did you install the BDE correctly? It should use the DBDEMOS files. Do you see such an alias in the BDE administration utility? Can you open that database in one of the Delphi demos?
The BDE is not a XXI century database, it was developed twenty years ago and never upgraded lately. It's an obsolete tecnology, but because it comes still with every release of Delphi with a known database it is still often used in demos because nothing new has to be installed.
Anyway that file is not its configuration file. It's a sharing lock file to allow more than one user to use the database concurrently. Because it is a file based database without a central server, it has to use such kind of shared files. Usually its position is changed to a network share, but it defaults to C:\ for historical reasons.
Anyway it's not only the BDE still attempting to write in the prong directories. I still see a full bunch of applications attempting to write to C:\ (especially logs) or other read-only positions.
Using BDE Admin to change the location for PDOXUSRS.NET helped, but it wasn't sufficient. DevExpress did the right thing in specifying a relative folder for the data location, and the relative folder seems perfectly allright, but for some reason the DB can't find it.
Solution: under the \Demos\ folder find all the *.dfm files that contain the string
..\..\Data
and replace that string with the absolute path to the demos folder. That done, all the demos open correctly.
I know this message from our own applications. It has to do with security measures introduced with Windows Vista. The operating system trying to protect critical files denies access to them. There is a method how to bypass this mechanism without compromising security. Try to run your application in compatibility mode. When application is running in compatibility mode, read / write operations from / to system folders are redirected to "safe" directories located in C:\Users[Current User]\AppData\Local\VirtualStore.
More info on http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html.

log4net writing to file. How to open up permissions

I was happily using log4net with my WPF program on an XP machine and happily using a fileAppender FileAppender to write log messages to c:\log.txt. All was well. However, it does not work on a Windows 7 machine. No error or anything, just that the file isn't created, much less logged to. A little research reveals that it's a file permissions problem (UAC) with Windows 7, and in fact it works if I run the executable as administrator. It doesn't work if I just click on it (even though I'm logged on as administrator) and it doesn't work when I launch from Visual Studio.
Questions:
1. Can someone point me to an example where I ask for permission to write to one and only one file (C:\log.txt). I've seen some examples of where the app.config is configured to ask that the whole program is run with admin privileges. This seems like overkill but I guess it would work.
2. Is there as better way to send the information to a log file? After all, perhaps C: does not exist on user machine. I think I recall the idea of a "user partition" in Windows 7, but whatever I do has to work on XP and Vista.
Thanks a ton,
Dave
You should not be trying to write directly to the root folder. Under windows 7, you will either have to run as administrator or disable UAC for that to work and neither are recommended.
Instead you can write to a folder in the 'application data' area
If you are using a .config file to configure log, you can use something like
<file value="${ALLUSERSPROFILE}\CompanyName\ProductName\Log.txt" />
or
<file value="${APPDATA}\CompanyName\ProductName\Log.txt" />
depending on whether you want the log files to be specific to a user or not.
(Obviously you replace CompanyName and ProductName with your own details).
This should work on Xp/Vista/W7.
You have 3 options in my eyes:
like mentioned always run your app as admin altough thats not a brilliant solution
Use the local path of the executing app to store your log - I always prefer this method as I always know where my logs are ( AppDomain.CurrentDomain.BaseDirectory will help you)
Use "My Documents" or some similar special folders - a quick google gives us: special folders
I hope this helps.

How do I find the database file on an Android virtual device?

My plan is to prepopulate a database on a virtual device and then include database in the distribution of my app.
However, I can't find the database file.
Is it on my hard disk some where?
How do I get it?
I tried connecting using adb, I did an "ls" and then got really scared by this obscure list of directories:
sqlite_stmt_journals
cache
sdcard
etc
system
sys
sbin
proc
init.rc
init.goldfish.rc
init
default.prop
data
root
dev
Even when I cd over to /data/data/your.package.here/databases I still do not have access to the actual database file. I can't use sqlite3 or do a pull on it. Is there a way to change permissions?
This works fine on my emulator, but fails on the actual device
adb pull /data/data//databases/mydb.db .
It should be in /data/data/your.package.here/databases, where your.package.here represents the package associated with your application, as defined in your AndroidManifest.xml file.
If you want to navigate to your database (which is located /data/data/your.package.here/databases), make sure you are a root user while navigating shell. To do so, type "su" once you enter the command prompt. When you are a root user, you can navigate wherever you want.
The blog post below gives a good solution of how to find and access your database. The post talks about using busybox, which provides useful utilities at the command line, to find your database and gives a few useful examples on how to use sqlite3 to access the DB and tables.
http://davanum.wordpress.com/2007/12/11/android-how-to-poke-around-the-sqlite3-databases/

Resources