I am writing a Xamarin.Forms app for Android using C#. I setup the Sqlite dB at: System.Environment.SpecialFolder.Personal
When the app is deployed on device I can add data and then retrieve it.
However, when I check the app next day(offline, without debugging from pc) all the dB data is gone.
Does it mean that the dB file is gone after some time?
Data from DB should not gone.
Are your sure that your DB initialization code is ok? Maybe every time you started the app, tha data is restoring to some start state?
The mysterious dissappearance of data in a sqlite db can have multiple causes.
Make sure that your db file exists, maybe you can implement a small debug button somwhere which will throw an alert which tells you if the file exists.
However using System.Environment.SpecialFolder.Personal shouldn't be the cause, I use that folder for my apps as well.
Second, do you actively commit your transactions? Especially when your app gets backgrounded, i would recommend calling Commit() in order to make sure that every pending transaction gets written into database, since you never know when the garbage collector comes around while your app is backgrounded.
If you are working with multiple threads, make sure that you are opening your database in a mode supporting a multithreaded environment.
If you open your sqlite db with a simple
SQLiteConnection conn = new SQLite.SQLiteConnection(path);
the database will open single-threaded.
Try this instead:
SQLiteConnection conn = new SQLite.SQLiteConnection(path, SQLiteOpenFlags.Create | SQLiteOpenFlags.ReadWrite | SQLiteOpenFlags.NoMutex);
If that doesn't help, please give a bit more insight into your code (how do you open the db, how do you insert/update data, etc...)
Related
I am working on a cross-platform app with a Sqlite DB. However, it only seems to retain an older copy of the db. If I go into the app, re-download the DB, which is supposed to delete the old one and replace it with more current info. It seems to work, everything looks correct. However, when I close the app and restart it, the old DB info is back with no record of the new data that was downloaded minutes ago.
This is the routine used to clear the old data.
public Task<int> ClearTableAsync<T>() where T : new()
{
return database.ExecuteAsync("DELETE FROM "+ typeof(T).Name);
}
The DB stored on the device is just a copy of a centrally stored DB. How do I make the newly stored info permanent?
You do not need to call SaveChanges? May be you just work in memory and you must commit the transaction/operation on physically db file.
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
I am writing a plugin for a C# application which uses SQLite database. The initial database is stored in database.db.default. At any point during runtime the user should be able to reset the database to the default content.
Since the application has always an open connection to the database I can not just copy database.db.default to database.db.
Whether or not it is a good idea to always hold an open connection is a total different question. But that is just how it is since it is not my call to change that part of the application.
Is there any way I am able to restore database.db.default into database.db using C# and .NET 3.0?
I appreciate any kind of help ...
If you can't do a file copy to restore the database then do the restore the hard way. Attach the backup database, delete all the data in the main database, then insert the data from the backup database.
I'm probably missing something here, but can't you just close your connection and reopen it after the copy?
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.
In some projects, but not all, when I open a designer for the first time (either WinForms or typed dataset) Visual Studio thrashes the disk for up to 30 minutes while freezing (this appears to be reads and writes with between 100 and 140 pages\sec).
Once it has done it the first time for a project, it's fine opening other projects until I close and re-open VS where it will freeze/thrash again the first time I open a designer.
Does anyone else see this, what the hell is it doing, and is there anything I can do to stop it?
It sounds like you are either running short on RAM and opening a designer puts it over the top or your hard disk needs to be defragmented.
It could be registry fragmentation too. Try pagedefrag.
OK, so it looks like it was defunct database connections in the Server Explorer tab:
A database on our test server was removed without my knowledge, but my project still had a data connection set up for it. It seems that whenever a table adapter is initialised in the designer, VS tries to connect to all the databases in the data connections list causing issues if the database does not exist. It even tries to connect to data connections that are not used by the current table adapter.
Some of our WinForms were badly written (naughy devs!) and were loading data in the constructors without checking for 'DesignMode' - these have been repaired.
Herbie