I have a Microsoft SQL database that is currently connected to a winforms C# application, it works fine on the single computer, but i would like it to be usable on a CD for any user.
I tried putting it in as a localDb but for some reason the database is duplicated and put into the bin folder, it causes multiple issues in recording data, for instances i save user ID 5 it saves in bin but never makes changes to the real database. Then next i go to create it, the user ID changes to 7 with user 6 not visible in either two databases (yes it is auto incremented by 1)
Any suggestions or best methods on making a database useable and readable via CD if the winform application is also on the CD
I have not tried this my self, but according to the documentation SQLite supports read-only databases.
If the file is read-only (due to permission bits or because it is located on read-only media like a CD-ROM) then SQLite opens the database for reading only. The entire SQL database is stored in a single file on the disk. But additional temporary files may be created during the execution of an SQL command in order to store the database rollback journal or temporary and intermediate results of a query.
see https://www.sqlite.org/c_interface.html
.NET SQLite providers are available here:
https://github.com/praeclarum/sqlite-net
http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
Related
I am developing a software using a MSSQL database for holding the data. In the program I implemented a function for creating a backup with SMO.
Now I am trying to implement a restore function. It works without any problems when the user has to insert the path manually. But I want to implement a select file dialog like this one the SQL Server Management Studio (SSMS) is opening when selecting a custom medium (see on the screenshot).
I already found the Microsoft.SqlServer.Management.Smo.Server class with the method EnumDirectories, but it returns only directory names and no files. When I confirm the selection I need the path in format C:\Directory\FileName.bak.
Is it possible to meet my needs with using SMO?
Many months ago I found a solution. I just developed a custom SelectFileDialog which is able to connecto to SQL server and work with the following SQL functions:
For searching available drives:
exec xp_fixeddrives
For reading folders and files:
exec xp_dirtree 'PATH', 1, 1
The PATH variable is dynamicly replaced depends on which folder is expanded by the user. It works without problems.
i've created a c# application that is effectively a workflow system that moves XML documents around folder structures depending on their status, among other things.
What i'd now like to do is use a database to store the XML files instead of local folders, but I still need to be able to query them with Linq / XQuery. I've chosen eXist-DB as my database it is gets some fairly good praise.
My question is, how do I connect to my newly created DB from my C# application. If i choose the 'Connect to a DB' option in Visual Studio i'm presnted with a bunch of SQL server options, but nothing that appears to be of any use to connect to my nice new eXist DB.
I have a C# .NET Framework 4.0 desktop application with Entity Framework as DAL.
When a try to save a data into DBContext on anybodies machine but mine, I recieved an exception
Failed to update database "*.mdf" read only
I keep my DB near .exe file, in folder "DAL/AppData".
How can I allow write access on other machines?
Can I do it programmatically?
I've read that I can place DB into AppRoaming Folder, but this is not my variant.
Thanks in advance.
I keep my DB near .exe file, in folder "DAL/AppData".
Yes. Can it be you mean that this is in the programs file folder, you know.
THe one that windows specs of the last 10 years say is "read only" for normal users?
OUCH.
THer are folders for storing data. There is a SpecialFolders enumeration to get the valid path of every such folder.
How can I allow write access on other machines? Can I do it programmatically?
On a SQL Server, this is done by allowing the other computer to access the server, not the data files. I.e. you connect to the SQL Server on the other machine, which is having the database loaded.
I've read that I can place DB into AppRoaming Folder, but this is not my variant.
First, that would be stupid unless you do actually plan for roaming - SQL shold go into a local folder, never roaming.
Second, "not my variant" is like "Hey, I drive the car against the rules, what can I do not to get speeding tickets". And "following the law is not my variant". Your variant is something WIndows does not care for. Learn how to install your software according to the windows guideline which is VERY clear where changing data should NOT be.
I never see database files in the installation folders of random programs, yet they obviously have one. My question is how do they do it?
EDIT: My database can be either on SQL Server, MySql, or Access I'm not bothered, however I would like the client to not have to download SQL Server or any other programs in order to be able to use mine.
You never see database files in the installation folders because installation folders are meant for programs, not for data. The data go into the appdata folders, such as "C:\Documents and Settings\User1\Application Data\Company1\Application1" or "C:\Users\User1\AppData\Company1\Application1" depending on your OS.
I never see database files in the installation folders of random programs yet they obliviously have one
If they are oblivious to database files then they don't need them. That is why you don't see them.
You can place the database file in Hidden Mode so that user can't see it until and unless he has Show Hidden Files option true
Or instead of placing database file along with exe you can place in dedicated application directory like C:\users\username\appdata\yourapp\
My suggestion would be to store your own database as a flat XML file (for example, a plain .NET DataSet saved to file via DataSet.WriteXml ) then apply your own fixed encryption to that file. the key to encrypt/decrypt will be inside your program code and need never be altered. By storing your own data as XML you wont need a client. At the start of your program, Read and decrypt your datafile into memory, then save and encrypt out when needed.
I'm building an application which will use some settings and a local SQL Server. My question is, when it comes time to update the application; will the settings or data be overwritten?
What happens if I want to change some tables around in the future?
Frankly, I've always thought that ClickOnce's way of handling data is dangerous. If you deploy a database with ClickOnce, it puts it in the DataDirectory. Then when you deploy an update to the application, it copies the database forward to the folder where the next version of the app is installed. But if the database changes, it copies it forward to the folder + \pre, and puts a new one in the datadirectory. If you don't realize you changed it, it replaces it anyway. If you so much as open a SQLCE database and check out the data structures, wham it gets deployed. Surprise!
I think storing the data in another folder under the user's profile makes more sense, and is safer. Then YOU can choose when to update your database. This article will show how to move your data so it's safe from ClickOnce updates.
Additionally, when you DO want to make changes to your database, you can use SQL statements to do so, such as "ALTER TABLE" and so on. I've created a script and deployed it as one long string (with carriage returns in it) and had the application split the resource apart by carriage return and execute the statements one by one. You get the general idea.
One comment about user settings -- You can change these programmatically via the UI (i.e. give the user the capability). But note that if you change the certificate of your application and are running a high enough version of .NET (3.5, 4), it won't cause you a problem per se, but it DOES have a different identity as a ClickOnce application, and the user settings are not carried forward when the next update is published. For this reason, I also rolled my own XML file for config data, and I store it in LocalApplicationData as well.
User-level settings will not be overwritten during an update via ClickOnce, but you can push new application-level settings, because the [YourExeName].exe.config file will be overwritten during an update.
If you need to overwrite user-level settings, you will have to do this programmatically.