We Keep Coding

How to update database.. .mdf is read only after deployment [duplicate]

I've created a database windows application using in C#. My application is running successfully on Windows XP, but it doesn't properly execute on Vista or Windows 7 systems. My application shows a message similar to
Failed to update .mdf database because the database is read-only
Can anyone give me a solution to this?

The big thing that changed between Windows XP and Windows Vista/7 is the introduction of UAC which means that users, even if created as administrators, don't routinely have read/write access to "important" locations such as the %programfiles% (Usually C:\Program Files or C:\Program Files (x86)) directory. This is why your application works on Windows XP and not on Windows Vista.
You need to store your DATA in the %programdata% directory (which is usually C:\ProgramData) if the data is shared between users on the machine or %appdata% (which is usually C:\Users\USERNAME_GOES_HERE\AppData\Roaming) if it is specific to a given user. You'll now no longer encounter the problem of being unable to write to the file.
The reason for this is that by storing data in your programs installation directory you were doing the wrong thing. Windows didn't stop you from doing this previously, but it was fairly widely documented that %programfiles% was not the appropriate place to store data.

If the MDB file is in your application path, then the default permissions would require elevation of rights to be able to write to the files -- I'd recommend moving the data to the ApplicationData shared folder, where end users will have write permissions by default

I ran into this related to localdb, the file is named:
myfolder/mysolution/myproject/App_Data/something.mdf
The way I fixed it is to right-click on the top level folder (myfolder) and then choose Properties, then choose Edit, then select Users, add to users either the Modify permission or both Modify and full control (this is a development environment) and then click apply.
So in other words, in my experience, it doesn't matter what folder you put the localdb in, you just need to give Users permission to write.

You should add the Modify permissions for IIS_IUSRS user to *.mdf file.

go to the folder Where the program is installed and right click on the database file and Properties -> Security -> Group or Username (Click users one by one and see below for the permissions)
If for the user if not set to full control, then click EDIT -> Select the user and give full control..

not able to open a file from share drive

I was trying to browse a file(S:\Scalable Development\DRD_ToolPointManagement.doc) from shared location trough web browser using application. when I run my application in local, it is working where as if I push the code to dev and QA environment, not able to open a file

There are two different problems, firstly using a mapped drive and secondly access rights to the folder. Both of these depend upon which account the application is running under. Have a look at http://www.iis.net/learn/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis
You need the built in group IIS_WPG which covers the application pool to have access to the network drive. If the S: drive is not mapped on the web server, you will also need to use the UNC path. If you look in Windows Explorer, your S: drive will appear something like
myshare (\\myserver) (S:) which should be translated to \\myserver\myshare\Scalable Development\DRD_ToolPointManagement.doc
Your domain administrator may need to allow access to the network share, and you may need to consider impersonation

When using the Web browser control, you're using the Internet Explorer. Thus, security settings may apply.
You need to change these in the Control Panel's internet settings of every machine you want to deploy to.
For example you may have to add the location to the trusted zone. Also, the target IE may not be configured to open Office documents in-place.

Solution for a no-server multi-user application/database?

I am at a dead end an I could really use some help.
I intern for a huge company. My projects involves creating an application to automate/simplify the work of a retiring employee.
The problem here lies in the strict company policies. I am a developer stuck at business end of the company. Therefor IT gives me nothing:
I don't have a server (nor web nor database)
I can't create a server, because no pc will be running and we can't keep them logged in due to single sign on with company cards.
I can't install anything on the pc's in the network.
I can access a share file server, that is backed up every day.
The libraries involved have to be free
A central database has to be accessed by a dozen of users (at once)
The database will recieve new data every day and will grow accordingly
The users will both read and write from/to the database
Preferably C#.NET or WPF solution
Application needs to open files stored on the shared drive. ( Only once, the important information will be extracted and stored in the database.. the file will then be removed)
My initial idea was to use silverlight (which runs standalone) in combination with SQLite. I ran a test and Silverlight files stored on the shared drive work. (Silverlight is installed on every pc on the network) This is my preferred front end. However (correct me if i'm wrong) I tried SQLite-net and I needed to add the sqlite3.dll to my windows/system32 folder, but on the network PC's I don't have access to the Windows folder, so this can not be done.
Also I read that SQLite or files in general can become corrupt when accessed by multiple users as one, so maybe I thought locking was an idea.
Which solutions are there to my problem?

I worked for a company for several years writing software for police departments to manage traffic collision reports. Police stations usually have little-to-no IT support, so we faced many similar limitations. The company actually did pretty well using Microsoft Access databases, with the setup looking something like this:
The shared drive had an Access database file (.mdb or .accdb) which was the actual "database".
Client computers (at the officers' desks) had Access applications with local "utility" tables for temporary storage, UI defined in Forms, and logic defined in Modules. Each of the client machines were connected to the repository on the shared drive by using linked tables. Local client configuration was stored either in the Access application in a config table, or in a text file on the machine.
It's not the cleanest solution, but it would allow you to create and maintain a unified solution using files that don't need to be installed and don't require any funny permissions, as long as everyone has read/write access to the shared drive.

Create a website. Today you can host ASP web apps in a stand alone .exe. By doing so you can make sure that the shared files are only accessed by one process. You can also limit the access to sqlite.
It also means that you do not have to distribute anything. Simply start your application and tell your users which url and port they have to browse too.
As for permissions, only the account running your webhost requires access to shared files etc.

You should take a look at ScimoreDB. It's an embedded database that supports multi-process read/write access. If needed it can also act as a client/server database; even as a distributed database with multiple nodes.
It's free to use and deploy. It has support for C++ and .NET. Only disadvantage is that it only works on Windows.

Access db creating problems

I have created a windows application with access on its backend. the problem is that when I installed it it shows operation must use updateable query when i try to insert or update operation ....After this I changed permission of folder where access database resides.Now it works fine.Now the problems is that on each computer where i install it I need to change write permissions on database folder in program files . Is there any solution for this where I can set permissions for my folder at setup creation time. or any other solution u know.....thanks in advance

Don't put your database in your program folder.
In the newest operating system like Win7 or Vista this folder is read-only for security reason.
The best place is the folder identified by the enum SpecialFolder.ApplicationData.
You get the physical path with:
string commonAppData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
Inside this path you should have a dedicated path for your application.
string myDataPath = Path.Combine(commonAppData, "MyApplicationDataFolder");
This scenario is good only if the application is not used by more than the user who installed the software. If you require a multiuser access to your database then you create by yourself a folder on the local disk or in a network share where each user can reach the database.
Usually the work of placing the database backend on the user machine or in a network share is reserved to the installation tool. Numerous tools exist on the market, free and paid. I don't know which tool you use and I can't suggest one or another. However when you select/use one you should check for the presence of these base functionality:
Ability to refer to the special folders present in the Windows
Environment. (MyDocuments, ApplicationData, etc...)
Ability to create sub-folders in these special folders (MyApplicationData)
Ability to create network shares or use one already present
Ability to update your configuration file where you store your
connection string (string replacing)
If the deployment tool works as expected you don't need to do anything inside your application, you read the connectionstring from your config file and open the database.

Create a text file with exactly same content below and save the file having extension '.reg'.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted Locations\Location2]
"Path"="C:\\Program Files\\Microsoft Office\\Office12\\ACCWIZ1\\"
"Description"="Access default location: Wizard Databases"
Test this registry file with double clicking onthis. it will create anew entry in registry.
Save the reg file with your installer and run it with installer. You can execute this file from c# code also.
registry_hacks_reg

Dynamically load .dlls from network share not browsable on client PC -- WCF?

I'm architecting a WPF application using the PnP Composite Application Guidance. The application will be run locally, within our intranet.
Modules will be loaded dynamically based on user roles. The modules must therefore be accessible to the application through a network share, thus accessible from the client machines.
What I'd like to do is keep all the module .dlls in a location not accessible to staff, but still be able to provide them to the composite application when demanded and when the current user is authenticated to use that module.
My thought is to load the .dlls by streaming them down from a WCF service, where the WCF service (on the server) can access the .dll repository, but none of the client machines can access it. Authentication would also be handled by the service.
I suspect that I might be overcomplicating things somehow.
Is this something that can be done with a simple filesystem configuration and programmatically passing credentials when accessing the shared folder? If I do this, would access only be granted to the calling application, or would the logged-on user now be able to navigate to the shared folder?
Is this, in any way, a solved problem with MEF or any other project of which you're aware? (I hope this isn't LMGTFY-worthy -- I haven't been able to come up with anything.)

At Argonne National Laboratory we keep all sharable DLL and other objects (.INI files, PowerBuilder PBD libraries, application software, etc.) on a simple and internally public file server and objects are being downloaded over the network on a per need basis as defined by each client/server application. Thus we are minimizing the maintenance of middleware (Oracle Client, PowerBuilder, Java, Microsoft, ODBC, etc.) to a single file server location with basically no software installed on the end user PC. Typically we physically download less than a few KB Registry Keys to the individual end user PC; this includes the full Oracle Client, which if installed on the PC alone would take up 650+ MB disk space and several thousand Registry Keys, and costly to maintain on the enterprise. Instead our Oracle Client on the PC is about 17KB.
The only “software" on the client side are Registry Keys containing variables pointing to server locations (f.ex. ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g ).
This has been a very cost effective solution we have been using for 10+ years, making all middleware and application software upgrades totally transparent to more than 2000 users Lab wide. Over the years we have done thousands of object upgrades on the central file server without ever having to install a single upgrade on the end user Desktop. Although this has some risks (“thou shall not copy DLLs over the network”, etc.) and is a heavily customized solution, it has worked flawlessly for us throughout for a large number of applications and middleware.
This is a somewhat surprisingly simple solution in today’s advanced technology, but it has been totally efficient and cost effective for us. Several vendors (Citrix and others) have looked at our solution somewhat perplexed, but every vendor of deployment techniques who have seen our deployment has come to the same conclusion, basically: “you do not need us”.

when loading modules you need to keep in mind that:
Once loaded, an assembly can't be unloaded (unless you unload the entire application domain) - so if users can log in and out using the same instance, you may have a problem.
"the load context" matters (see http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - this may cause problems if you have dependencies between modules or dependencies on assemblies that are not in the "load context"
If the restricted access to dlls is due to a licensing issue, maybe you need to refine the licensing mechanism somehow (not tie it to access to the actual code, but to some other checks)?