I have two windows applications which will be accessing same database(stored in a hard disk). Only one of these two application is performing both read/write operations in this db while the second one only performs read operations. Do I need mutex/events to protect my db while both applications are accessing it? I was reading FAQ of SQLite which says that I might not need any resource protection, SQLite has in-built feature..
Related
I am trying to create an app that receives an Sqlite database from a server for offline use but cloud synchronization. The server has a postgres database with information from many clients.
1) Is it better to delete the sql database and create a new one from a query, or try to synchronize and update the existing separate sqlite files (or another better solution). The refreshes will be a few times a day per client.
2) if it is the latter, could you give me any leads to resources on how I could do this?
I am pretty new to database applications so please excuse my ignorance and let me know if there is any way I could clarify.
There is no one size fits all approach here. You need to carefully consider exactly what needs to be done, what you are replicating, how much data is involved, and what your write models are, all before you build a solution. Along the way you have to decide how to handle write conflicts and more.
In general the one thing I would say is that such synchronization works best with append-only write models (i.e. inserts, no deletes, no updates), and one way to do it is to log changes that need to be made and replicate those changes.
However, master-master replication is difficult on the best of days and with the best of tools available. Jumping between databases with very different capabilities will introduce a number of additional problems. You are in for a big job.
Here's an open source product that claims to solve this for many database types including Postgres. I have no affiliation or commercial interest in this company.
https://github.com/sqlite-sync/SQLite-sync.com
http://sqlite-sync.com/
If you're able and willing to step outside relational databases to use an object store you might want to have a look at CouchDb and perhaps PouchDb that use a MVCC based replication protocol designed to support multi-master replication including conflict resolution. Under the covers, PouchDb uses adaptors for Sqlite, IndexDb, Local storage or a remote CouchBb instance to persist client side data. It auto selects the best client side storage option for the given desktop or mobile browser. The Sqlite engine can be either WebSQL or a Cordova Sqlite plugin.
http://couchdb.apache.org/
https://pouchdb.com/
I've read in multiples websites that Azure doesn't support encryption.
However I'm migrating (more like a backup) an Azure DB to SQL Server using the "Azure SQL Migration Tool" and I'm getting a warning about scripting the views: "Encrypted objects will not be scripted".
Also found this note in their site: Problem fixed in v3.5.5. Basically, Stored Procedures, Views, UDF, Triggers ... any object that can be encrypted is check before hand. The objects that are encrypted are highlighted in yellow with red letters. On the summary page, a list of encrypted objects that will not be scripted will be displayed.
http://sqlazuremw.codeplex.com/workitem/5762
If Azure SQL supports encryption, how can I get the creation script for this view?
Windows Azure SQL Database (database-as-a-service) does not support encryption. However: If you run SQL Server in a Virtual Machine, you should have all features at your disposal, including encryption.
I can't explain what's happening with the migration from SQL Database to SQL Server, regarding creation scripts involving encrypted objects on the target side.
SQL Database still doesn't support encryption, so either you are reading from a SQL Server database, or there is a bug in the Wizard. There are no encrypted database objects in SQL Database as far as I know. If you are sure you are reading from SQL Database, just try creating an encrypted view in it and see what happens. From the MSDN documentation, creating an encrypted view is not supported: http://msdn.microsoft.com/en-us/library/windowsazure/ee336244.aspx.
I am curious to know if you are getting the same error with Enzo Cloud Backup: http://www.bluesyntax.net/backup20.aspx. Just use the free edition.
Is it possible to access a SQLite database running on a WP8 app from a Windows 8/Store/"Metro" app?
If yes, how - is there any trick to it? Is it easy, tricky, or impossible?
If impossible, is it possible with any other DB? AFAIK, SQLite is the only DB that can be used with the new Windows Store style sandboxed apps.
Have a look at this article. It explains that:
sqlite is only used for storing data locally (i.e. cache something from a remote data source)
you cannot connect to remote databases because that involves distributing your database connection string (i.e. username and password) to potentially millions of users
the correct way to provide data to your app is through some sort of service. Think about the different APIs major website have now.
So to answer your question: no, this is a bad idea.
Is anyone running SQLite in-memory db as their main database for their web app? I'm trying to get a handle on the feasibility/stupidity of such a setup.
If I have a web application with fewer than 500 concurrent users and a database that's smallish in size (between 0 and 4 GB), what's the feasibility of running SQLite in-memory with the entire database in it as the main database for the app?
Running in-memory would obviously make the "Durable" aspect of ACID difficult, but with the SQLite backup API, it seems like it's possible to keep an in-memory db in sync with a file-based db. I'm thinking that when a user executes a Save/Update/Delete command, it could instantly update the in-memory copy and then be queued to make it to the file-based db. Whenever the app gets cycled, it could just be loaded from the file-based db via the backup API, right?
According to the SQLite documentation, a single connection must be kept open in order to keep the in-memory db up and running, so is this a problem if it's kept open for hours or days?
You should only use an in-memory database for data processing, not to store data. Because you need to store the data on disk anyway, it's much simpler and more effective to store the database on disk in the first place.
If you need to sync the database to disk, why use an in-memory database? The advantage of an in-memory database is that data never needs to be written to a filesystem. Since you need data to be written to disk, you've turned the sole advantage into a disadvantage. So why do it? Just crank up the cache as large as you can.
I am using sqlite3 in a linux machine and I am getting the database without username and password. Can I set a username and password for the same?
No, sqlite3 databases are very lightweight systems. They need no server and all data is stored in one file. A username/password is not supported by the sqlite/sqlite3 package.
In order to achieve simplicity, SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth.
(sqlite, when to use)
However, since it's only a file you can encrypt the file with a password to protect your data.
SQLite doesn't have a concept of username/password. It's just a single file based database.
However, on Unix you can protect your database from other users on the same machine by setting the permissions of the database file itself.
e.g. Allow only owner access
chmod 700 /path/to/sqlitedb
If it's used in a simple web application then the web application will provide the control.
The prior answers are only partially true. You can have databases that require authentication but you'll have to compile SQLite separately from PHP.
See the SQLite User Authentication documentation for further information.
SQLite is mainly an embedded database engine, not intended to be used as a multi-user database server that would require usernames and passwords.
You can always encrypt the database file with some user-provided password/-phrase, I guess. But expecting an embedded DBMS to sport full-blown access control is too much.