Is it ok to use SQLite as a backend database in Datasnap ? Will there be a danger of database locking since SQLite is filebased or will the datasnap server provide the necessary backbone for this not to happen ?
I don't know about Datasnap, but with working directly with SQLite (...) I know SQLite is able to use one file/database from several processes and keep track of lock using mutexes. (See more about sqlite's mutex functions here) How they work exactly depends on which compile settings were used when building sqlite3.dll. I've been using the precompiled binaries from the website without any problem.
Related
I'm using flask on appfog.com to make a personal blog. Today I tried to use sqlite. I can run the application locally with sqlite but when I update the app to AppFog, it does not seem to work. I can't find how to use sqlite in AppFog's docs. Can anyone tell me?
Thanks...
Sorry for my poor english:-)
It's not recommended to use sqlite for your production apps on AppFog because the file storage is ephemeral. Every time you update your app the database will get blown away. You're better off creating and binding a postgres, mysql, or mongodb database service for your app. You can continue to use sqlite db locally but your production app will use the bound service.
See the Bind Service section of: https://docs.appfog.com/languages/python/flask
I would like to open and read an SQLite .db file, read-only. I guarantee that nobody else will touch it during this time (perhaps, except for read only).
What I need from SQLite3 in return, is that it will write nothing to disk, ever (specifically - none of those described here), and not use any file-system locks on the file.
Is that too much to ask?
If you are running under some Unix, you can use the unix-none VFS to disable all locking.
In Windows, SQLite always uses locks.
If you really want to avoid locks, you can either write your own VFS, or override the locking system calls with xSetSystemCall.
If SQLite needs a temporary file, you cannot prevent it from creating one.
However, you can configure it to create them in memory instead of on disk.
The VFS does not have a Lock method that can be injected. Therefore there is no a direct method to inject dummy LockFile and LockFileEx methods.
These methods are referenced inside sqlite3_io_methods (winIoMethod) and don't seem to be easy to modify in runtime without altering SQLite source code.
So, if I understand correctly, VFS is not the right direction? Or is it?
May be use a read-only user? I don't know if such role exists in SQL Lite.
I have been using a central MS SQL database located in the cloud to develop a web site project. I have recently found myself in situations, when I need to develop without the internet connection. I want to begin to use a locally available copy of the existing database, put it in App_Data folder.
What is the correct set of steps I need to undertake to get the project to work with local DB?
For example:
Detach a db from an existing SQL instance.
Copy to a development machine.
etc.
Moving a SQL-Server DB is not that hard. Look here for some methods to do it.
http://support.microsoft.com/kb/314546
I usually find the sp_detach + sp_attach method really easy.
I would create an empty shell database locally, then use one of the many schema comparison solutions available to make the local database look exactly like the cloud database.
Correct way is to create and regularly update your standalone copy of database using import/export. In particular MS SQL Server provides Import/Export Wizard tool for such purpose.
Make a backup
Copy backup file
Restore on your server
Restore/organise users
I want to provide iCloud support for my wrapper around sqlite. Is not using coredata.
I wonder how enable iCloud for it. The database content is changed all the time (is for invoicing). Also, if is possible to have some kind of versioning will be great.
Exist any sample I can use to do this?
The short answer is no, you would need to use Core Data as you suspected. Apple has stated that sqlite is unsupported.
Edit: Check out the section on iCloud that's now in the iOS Application Programming Guide under Using iCloud in Conjunction with Databases
Using iCloud with a SQLite database is possible only if your app uses
Core Data to manage that database. Accessing live database files in
iCloud using the SQLite interfaces is not supported and will likely
corrupt your database. However, you can create a Core Data store based
on SQLite as long as you follow a few extra steps when setting up your
Core Data structures. You can also continue to use other types of Core
Data stores—that is, stores not based on SQLite—without any special
modifications.
You can't just put the SQLite database in the iCloud container, because it might get corrupted. (As you modify an SQLite DB, temporary files are created and renamed, so if the sync process starts copying those files, you'll get a corrupt database.)
If you don't want to move to Core Data, you can do what Core Data does: store your database in your document folder, and store a transaction log in the iCould container. Every time you change the database, you add those changes to a log file, so you can play them back and make equivalent changes on other devices.
This gets pretty complicated: aside from getting the log/reply logic right, you'll want to coalesce redundant changes and periodically collapse the log into a complete copy of the database.
You might have an easier time developing a solution if you can exploit knowledge of your application (Core Data has to solve the problem in the general case). For example, you could save invoices as separate files in the cloud container (text, Property List, XML, JSON, whatever), writing them out as the database changes and only importing ones if the system tells you they were created or changed.
In summary, your choice is either to migrate to Core Data or write a sync solution yourself. Which one is best depends on the particulars of your application.
I have a Monotouch app which uses a sqlite database. I want to encrypt the database so I am doing this:
_mainConnection = new SqliteConnection("Uri="+finalDB);
_mainConnection.Open();
_mainConnection.ChangePassword("mypassword");
However, its not working (on simulator and iphone). It gets this error:
at (wrapper managed-to-native)
Mono.Data.Sqlite.UnsafeNativeMethods.sqlite3_rekey
(intptr,byte[],int) <0x0005c> at
(wrapper managed-to-native)
Mono.Data.Sqlite.UnsafeNativeMethods.sqlite3_rekey
(intptr,byte[],int) <0x0005c> at
Mono.Data.Sqlite.SQLite3.ChangePassword
(byte[]) <0x00053> at
Mono.Data.Sqlite.SqliteConnection.ChangePassword
(byte[]) <0x0004b> at
Mono.Data.Sqlite.SqliteConnection.ChangePassword
(string) <0x0005b>
Has anyone successfully used password protection on an sqlite database in Monotouch?
As per my research there are a few options for database encryption using MonoTouch. I have a forthcoming blog post on the subject, but for now these are your top two options:
SQLCipher
I've automated the SQLCipher build process substantially. All it takes is a simple make command and you've got a library that you can link into your project. It makes use of the awesome SQLite-NET library. After that, all that's required is to provide the key in the SQLite.cs file.
SQLCipherNet: https://github.com/anujb/SQLCipherNet
CSharp-SQLite
This is a managed port of the SQLite library in C#. Performance is only about ~2x slower, which is pretty awesome considering it's not native code!
Encryption: http://code.google.com/p/csharp-sqlite/wiki/ENCRYPTION
Perf Benchmarks: http://code.google.com/p/csharp-sqlite/wiki/Benchmarks
Try adding ";Password=mypassword" to your connection string, and remove the call to ChangePassword.
Please note that, by default, the iPhone implementation of sqlite does not support encryption, so the sqlite commands for that will be no-ops.
You can get a (paid) copy of the encrypt-able version of sqlite from http://www.hwaci.com/sw/sqlite/see.html, and compile it into your application, making sure to remove the libsqlite3*.dylib from your project if you've linked that in.
You may have to do a bit of digging in the Monotouch documentation and/or experimentation to make sure that the Monotouch library itself is not including the default sqlite implementation, but in fact links to the implementation you specify. Try it first, if things still don't work that's where I'd start looking.
You can do this experiment without paying for the encrypted version, simply using the sqlite3 source code available on the net, with appropriate break points.
Good luck!
PS: Note that there is no comparable solution for Android at this point, this works on iPhone because iPhone runs native C code.
PPS: There is also SQLCipher that claims to encrypt sqlite on iPhone. However I found the configuration requirements to be below my standards for simplicity. I'm also not sure if it will properly insert itself between Monotouch's framework code and the default iPhone sqlite implementation.
SQLCipher for MonoTouch provides full database encryption for SQLite databases.
http://sqlcipher.net/sqlcipher-for-monotouch
There is also a SQLCipher on Mono for Android, which allows you to reuse the same code across Mono Touch and MonoDroid applications
http://sqlcipher.net/sqlcipher-for-monodroid
Just thinking out loud but could this be due to sqlite's dynlib that comes with the iPhoneSDK not being threadsafe?
For an alternative you might try looking at WWDC Vid 209 and just lock/encrypt the DB when you're outside the app.
You can probably do it yourself by issuing a "pragma rekey" in a raw SQLite query -- that is, if the SQLite version installed is actually SqlCipher.
I had the same problem but with a windows form application in C#.
I could not find the solution so i had to encrypt my data manually when saving it and decrypt it when retrieving.