Re: [sqlite] pre-loading with nuget fails to copy SQLite Interop Library

Thanks a lot for your answer William. I understood and actually I found out that it is as you said: differently from previuos versions, now the x86/64 folders and interop files are copied to the bin folder without putting tham in the rrot of the project and setting for copying to the output

Re: [sqlite] ALTER TABLE .. ADD COLUMN .. IF NOT EXISTS ..?

On Tue, Dec 16, 2014 at 11:40:22PM +, Simon Slavin wrote: > If 'ALTER TABLE ... ADD COLUMN ...' fails it fails harmlessly, with But it doesn't fail so harmlessly: $ sqlite3 db 'alter table toy add column foo text; select 5;' || echo fail SQL Error: duplicate column name: foo fail $ Note

Re: [sqlite] ALTER TABLE .. ADD COLUMN .. IF NOT EXISTS ..?

On 16 Dec 2014, at 10:40pm, Nico Williams wrote: > I have a habit of putting schema definitions in a file that's always > safe to read and execute against a DB connection. This means that I > DROP some things IF EXISTS and CREATE all things IF NOT EXISTS. > > But if I

[sqlite] ALTER TABLE .. ADD COLUMN .. IF NOT EXISTS ..?

I have a habit of putting schema definitions in a file that's always safe to read and execute against a DB connection. This means that I DROP some things IF EXISTS and CREATE all things IF NOT EXISTS. But if I have to ALTER TABLE... there's no IF NOT EXISTS .. equivalent for ALTER TABLE. Funny

Re: [sqlite] Encrypted database

Am 16.12.2014 17:44, schrieb Keith Medcalf: Most freely available encryption extensions use a hard coded encryption method. This is true for System.Data.SQLite (128 bit RSA), SQLCipher (256 bit AES), and wxSQLite3 (128 or 256 bit AES, decided at compile time) to name a few. The official

Re: [sqlite] Encrypted database

>Most freely available encryption extensions use a hard coded encryption >method. This is true for System.Data.SQLite (128 bit RSA), SQLCipher >(256 bit AES), and wxSQLite3 (128 or 256 bit AES, decided at compile >time) to name a few. The official commercial SQLite Encryption Extension >(SEE)

Re: [sqlite] pre-loading with nuget fails to copy SQLite Interop Library

There were changes to the NuGet packages in 1.0.94 that may have something to do with what you're experiencing. Also, it looks like there are some NuGet bug fixes scheduled for the next release. I am using 1.0.94 Core with no issues (the x86/64 folders and interop files are copied to the bin

[sqlite] SQLITE_FTS3_MAX_EXPR_DEPTH and upgrading sqlite

Hello all, Apologies in advance if this question has been asked and answered elsewhere – a (brief, admittedly) search did not turn up anything and so I’m posting this. We’re in the process of upgrading sqlite in our service. We were on a version which did not have the compile option

Re: [sqlite] Encrypted database

Am 16.12.2014 14:03, schrieb jus...@postgresql.org: On 2014-12-16 11:42, Harmen de Jong - CoachR Group B.V. wrote: We use Navicat for SQLite and simply replaced the sqlite.dll file with our own compiled SQLite dll version that has the proper encryption included. Maybe this will work for you too

[sqlite] pre-loading with nuget fails to copy SQLite Interop Library

Hi all, I have a project in .net 4.5, I have been using System.Data.SQLite.Core assembly 1.0.86.0 from nuget with the preloading native library feature that copied in the folders x64 and x86 the corrensponding SQLite Interop Library. Now I would like to do the same with the latest packages from

Re: [sqlite] Encrypted database

On 2014-12-16 11:42, Harmen de Jong - CoachR Group B.V. wrote: We use Navicat for SQLite and simply replaced the sqlite.dll file with our own compiled SQLite dll version that has the proper encryption included. Maybe this will work for you too and allows you to use a management tool that is

Re: [sqlite] Encrypted database

We use Navicat for SQLite and simply replaced the sqlite.dll file with our own compiled SQLite dll version that has the proper encryption included. Maybe this will work for you too and allows you to use a management tool that is quite feature rich. Maybe this approach will work for other

Re: [sqlite] Abnormal memory usage when removing rows within nested transaction from a table, referenced by another table via FK,

> > > > > > > > > The memory is being used by the statement journal, which you have in > > > > memory. If the app did not set "journal_mode=memory" and > > > > "temp_store=memory", SQLite would create a really large temp file > > > > instead of using memory. Which would still be sub-optimal,