Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

in my SQLite.dll library program.

On Tue, Feb 21, 2017 at 2:42 PM, Clyde Eisenbeis  wrote:
> I don't recall how I obtained the SQLite files ... was two years ago.
>
> When I have SQLite installed on my genealogy program and on my SQLite
> .dll library, it works fine.
>
> When I don't have SQLite installed on my genealogy program, I get an
> exception "Unable to load DLL 'SQLite.Interop.dll': ... " with
>
>   sqliteConn = new System.Data.SQLite.SQLiteConnection("Data Source="
> + stPathFilename + ";").
>
> On Tue, Feb 21, 2017 at 12:26 PM, Barry  wrote:
>> Are you using NuGet or downloading the binaries from System.Data.Sqlite.org?
>>
>> Ah. You'll have to excuse me, it's been a while since I actually started a
>> new project and set SQLite as a dependency. I'm not sure if things have
>> changed, or if my memory is terrible, but what I said may not have been
>> completely clear or correct.
>>
>> If you're using NuGet (the easiest way):
>>  Turns out there's a NuGet package called System.Data.Sqlite.Core* that
>> includes only the core SQLite wrapper. If you install System.Data.Sqlite
>> you get the LINQ and EF stuff (which I generally try to stay away from). If
>> you use this package you will get both the x64 and x86 interop binaries in
>> their respective folders. If you have already installed the
>> System.Data.Sqlite package, and got the LINQ and EF dependencies, you
>> should be able to remove them as a dependency by right clicking the the
>> unnecessary dependencies to open their context menu, and selecting "Remove".
>>
>> If you're downloading from the website System.Data.Sqlite.org:
>>  You only get an x86 or a x64 version of the interop binaries, depending on
>> what you download. The download page has some instructions on how you can
>> make the wrapper library automatically select the correct interop dll for
>> whichever architecture you're targetting. See the section entitled "Native
>> Library pre-loading". I haven't gone through this setup personally so
>> cannot help you any more than what is there on the site (The NuGet package
>> comes with this preconfigured). You can choose to download the mixed mode
>> assemblies which will not have the 'interop' DLLs. I haven't played around
>> with these because the download page specifically advises to avoid these
>> packages unless you need to put SQLite in the Global Assembly Cache (which
>> the authors also recommend against). Note that if you download from the
>> website, you'll get the LINQ and EF6 dlls included in the zip file. If you
>> never reference them from your project, they won't be copied to your output
>> directory and you can ignore them.
>>
>> Hope this helps. I am by no means an expert, I've only messed with it a few
>> times. I hope that if I have got things wrong that someone more experienced
>> can jump in and correct my mistakes.
>>
>> * This name might be a little confusing since Microsoft have recently
>> release an unrelated product called Entity Framework Core. It appears
>> unrelated to System.Data.Sqlite.Core.
>>
>> On 21 February 2017 at 13:48, Clyde Eisenbeis  wrote:
>>
>>> Thanks for the good info!
>>>
>>> I can't find SQLite.Interop.dll ... is referenced at
>>> https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki,
>>> but don't see a download.
>>>
>>> On Mon, Feb 20, 2017 at 12:30 PM, Barry Smith 
>>> wrote:
>>> > I would use system.data.sqlite in that situation.
>>> >
>>> > But I would also say it depends on what you already have written, and
>>> what your strengths are. I am under the impression from your first email
>>> that you already have something written using system.data.sqlite. i.e.
>>> Using the class System.Data.SQLite.SQLiteConnection to create a
>>> connection to the db, then using the methods of that to manipulate the db
>>> or extract data from it. Have I assumed wrong?
>>> >
>>> > If I am wrong, and you have yet to start writing anything, I would still
>>> recommend using system.data.sqlite. Only if you particularly like LINQ over
>>> SQL and you are prepared to learn the caveats of the entity framework would
>>> I recommend that.
>>> >
>>> > Note that if you're using system.data.sqlite you will ultimately produce
>>> a few dlls that must be distributed together:
>>> >  - your custom library, which contains the code you've written
>>> >  - System.Data.Sqlite.dll, which contains the wrapper to make an
>>> interface to access SQLite in a more dotNet friendly manner
>>> >  - x64\sqlite.interop.dll
>>> >  - x86\sqlite.interop.dll
>>> > The last two contain the 'raw' SQLite library (for either 32 or 64 bit
>>> systems).
>>> >
>>> > You should not need the other libraries for a simple application. If you
>>> find that visual studio is placing them in your project's output directory,
>>> check if they are listed as a reference and try to remove them then
>>> recompile.
>>> >
>>> >> On 20 Feb 2017, at 1:05 

Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

I don't recall how I obtained the SQLite files ... was two years ago.

When I have SQLite installed on my genealogy program and on my SQLite
.dll library, it works fine.

When I don't have SQLite installed on my genealogy program, I get an
exception "Unable to load DLL 'SQLite.Interop.dll': ... " with

  sqliteConn = new System.Data.SQLite.SQLiteConnection("Data Source="
+ stPathFilename + ";").

On Tue, Feb 21, 2017 at 12:26 PM, Barry  wrote:
> Are you using NuGet or downloading the binaries from System.Data.Sqlite.org?
>
> Ah. You'll have to excuse me, it's been a while since I actually started a
> new project and set SQLite as a dependency. I'm not sure if things have
> changed, or if my memory is terrible, but what I said may not have been
> completely clear or correct.
>
> If you're using NuGet (the easiest way):
>  Turns out there's a NuGet package called System.Data.Sqlite.Core* that
> includes only the core SQLite wrapper. If you install System.Data.Sqlite
> you get the LINQ and EF stuff (which I generally try to stay away from). If
> you use this package you will get both the x64 and x86 interop binaries in
> their respective folders. If you have already installed the
> System.Data.Sqlite package, and got the LINQ and EF dependencies, you
> should be able to remove them as a dependency by right clicking the the
> unnecessary dependencies to open their context menu, and selecting "Remove".
>
> If you're downloading from the website System.Data.Sqlite.org:
>  You only get an x86 or a x64 version of the interop binaries, depending on
> what you download. The download page has some instructions on how you can
> make the wrapper library automatically select the correct interop dll for
> whichever architecture you're targetting. See the section entitled "Native
> Library pre-loading". I haven't gone through this setup personally so
> cannot help you any more than what is there on the site (The NuGet package
> comes with this preconfigured). You can choose to download the mixed mode
> assemblies which will not have the 'interop' DLLs. I haven't played around
> with these because the download page specifically advises to avoid these
> packages unless you need to put SQLite in the Global Assembly Cache (which
> the authors also recommend against). Note that if you download from the
> website, you'll get the LINQ and EF6 dlls included in the zip file. If you
> never reference them from your project, they won't be copied to your output
> directory and you can ignore them.
>
> Hope this helps. I am by no means an expert, I've only messed with it a few
> times. I hope that if I have got things wrong that someone more experienced
> can jump in and correct my mistakes.
>
> * This name might be a little confusing since Microsoft have recently
> release an unrelated product called Entity Framework Core. It appears
> unrelated to System.Data.Sqlite.Core.
>
> On 21 February 2017 at 13:48, Clyde Eisenbeis  wrote:
>
>> Thanks for the good info!
>>
>> I can't find SQLite.Interop.dll ... is referenced at
>> https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki,
>> but don't see a download.
>>
>> On Mon, Feb 20, 2017 at 12:30 PM, Barry Smith 
>> wrote:
>> > I would use system.data.sqlite in that situation.
>> >
>> > But I would also say it depends on what you already have written, and
>> what your strengths are. I am under the impression from your first email
>> that you already have something written using system.data.sqlite. i.e.
>> Using the class System.Data.SQLite.SQLiteConnection to create a
>> connection to the db, then using the methods of that to manipulate the db
>> or extract data from it. Have I assumed wrong?
>> >
>> > If I am wrong, and you have yet to start writing anything, I would still
>> recommend using system.data.sqlite. Only if you particularly like LINQ over
>> SQL and you are prepared to learn the caveats of the entity framework would
>> I recommend that.
>> >
>> > Note that if you're using system.data.sqlite you will ultimately produce
>> a few dlls that must be distributed together:
>> >  - your custom library, which contains the code you've written
>> >  - System.Data.Sqlite.dll, which contains the wrapper to make an
>> interface to access SQLite in a more dotNet friendly manner
>> >  - x64\sqlite.interop.dll
>> >  - x86\sqlite.interop.dll
>> > The last two contain the 'raw' SQLite library (for either 32 or 64 bit
>> systems).
>> >
>> > You should not need the other libraries for a simple application. If you
>> find that visual studio is placing them in your project's output directory,
>> check if they are listed as a reference and try to remove them then
>> recompile.
>> >
>> >> On 20 Feb 2017, at 1:05 PM, Clyde Eisenbeis  wrote:
>> >>
>> >> Thanks for the clarification.  In my case:
>> >>
>> >> 1) Speed is not an issue.  Size is not an issue.
>> >>
>> >> 2) This is a personal use database 

Re: [sqlite] SQLite Options

[Barry]

Are you using NuGet or downloading the binaries from System.Data.Sqlite.org?

Ah. You'll have to excuse me, it's been a while since I actually started a
new project and set SQLite as a dependency. I'm not sure if things have
changed, or if my memory is terrible, but what I said may not have been
completely clear or correct.

If you're using NuGet (the easiest way):
 Turns out there's a NuGet package called System.Data.Sqlite.Core* that
includes only the core SQLite wrapper. If you install System.Data.Sqlite
you get the LINQ and EF stuff (which I generally try to stay away from). If
you use this package you will get both the x64 and x86 interop binaries in
their respective folders. If you have already installed the
System.Data.Sqlite package, and got the LINQ and EF dependencies, you
should be able to remove them as a dependency by right clicking the the
unnecessary dependencies to open their context menu, and selecting "Remove".

If you're downloading from the website System.Data.Sqlite.org:
 You only get an x86 or a x64 version of the interop binaries, depending on
what you download. The download page has some instructions on how you can
make the wrapper library automatically select the correct interop dll for
whichever architecture you're targetting. See the section entitled "Native
Library pre-loading". I haven't gone through this setup personally so
cannot help you any more than what is there on the site (The NuGet package
comes with this preconfigured). You can choose to download the mixed mode
assemblies which will not have the 'interop' DLLs. I haven't played around
with these because the download page specifically advises to avoid these
packages unless you need to put SQLite in the Global Assembly Cache (which
the authors also recommend against). Note that if you download from the
website, you'll get the LINQ and EF6 dlls included in the zip file. If you
never reference them from your project, they won't be copied to your output
directory and you can ignore them.

Hope this helps. I am by no means an expert, I've only messed with it a few
times. I hope that if I have got things wrong that someone more experienced
can jump in and correct my mistakes.

* This name might be a little confusing since Microsoft have recently
release an unrelated product called Entity Framework Core. It appears
unrelated to System.Data.Sqlite.Core.

On 21 February 2017 at 13:48, Clyde Eisenbeis  wrote:

> Thanks for the good info!
>
> I can't find SQLite.Interop.dll ... is referenced at
> https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki,
> but don't see a download.
>
> On Mon, Feb 20, 2017 at 12:30 PM, Barry Smith 
> wrote:
> > I would use system.data.sqlite in that situation.
> >
> > But I would also say it depends on what you already have written, and
> what your strengths are. I am under the impression from your first email
> that you already have something written using system.data.sqlite. i.e.
> Using the class System.Data.SQLite.SQLiteConnection to create a
> connection to the db, then using the methods of that to manipulate the db
> or extract data from it. Have I assumed wrong?
> >
> > If I am wrong, and you have yet to start writing anything, I would still
> recommend using system.data.sqlite. Only if you particularly like LINQ over
> SQL and you are prepared to learn the caveats of the entity framework would
> I recommend that.
> >
> > Note that if you're using system.data.sqlite you will ultimately produce
> a few dlls that must be distributed together:
> >  - your custom library, which contains the code you've written
> >  - System.Data.Sqlite.dll, which contains the wrapper to make an
> interface to access SQLite in a more dotNet friendly manner
> >  - x64\sqlite.interop.dll
> >  - x86\sqlite.interop.dll
> > The last two contain the 'raw' SQLite library (for either 32 or 64 bit
> systems).
> >
> > You should not need the other libraries for a simple application. If you
> find that visual studio is placing them in your project's output directory,
> check if they are listed as a reference and try to remove them then
> recompile.
> >
> >> On 20 Feb 2017, at 1:05 PM, Clyde Eisenbeis  wrote:
> >>
> >> Thanks for the clarification.  In my case:
> >>
> >> 1) Speed is not an issue.  Size is not an issue.
> >>
> >> 2) This is a personal use database (genealogy).
> >>
> >> 3) Typically I create .dll's that serve as a library (WPF Custom
> >> Control Library) ... easy to use for different programs.
> >>
> >> 4) For example, I have an Excel .dll library (uses Excel as a
> >> database).  When the program runs the first time using this .dll
> >> library, it creates the Excel file along with multiple sheets.
> >>
> >> 5) I'd like to create a similar .dll for an SQLite library.  The
> >> program that uses this .dll is a simple WPF program that uses the .dll
> >> class name to access the functions.
> >>
> >> With this info, which option would 

Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

Thanks for the good info!

I can't find SQLite.Interop.dll ... is referenced at
https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki,
but don't see a download.

On Mon, Feb 20, 2017 at 12:30 PM, Barry Smith  wrote:
> I would use system.data.sqlite in that situation.
>
> But I would also say it depends on what you already have written, and what 
> your strengths are. I am under the impression from your first email that you 
> already have something written using system.data.sqlite. i.e. Using the class 
> System.Data.SQLite.SQLiteConnection to create a connection to the db, then 
> using the methods of that to manipulate the db or extract data from it. Have 
> I assumed wrong?
>
> If I am wrong, and you have yet to start writing anything, I would still 
> recommend using system.data.sqlite. Only if you particularly like LINQ over 
> SQL and you are prepared to learn the caveats of the entity framework would I 
> recommend that.
>
> Note that if you're using system.data.sqlite you will ultimately produce a 
> few dlls that must be distributed together:
>  - your custom library, which contains the code you've written
>  - System.Data.Sqlite.dll, which contains the wrapper to make an interface to 
> access SQLite in a more dotNet friendly manner
>  - x64\sqlite.interop.dll
>  - x86\sqlite.interop.dll
> The last two contain the 'raw' SQLite library (for either 32 or 64 bit 
> systems).
>
> You should not need the other libraries for a simple application. If you find 
> that visual studio is placing them in your project's output directory, check 
> if they are listed as a reference and try to remove them then recompile.
>
>> On 20 Feb 2017, at 1:05 PM, Clyde Eisenbeis  wrote:
>>
>> Thanks for the clarification.  In my case:
>>
>> 1) Speed is not an issue.  Size is not an issue.
>>
>> 2) This is a personal use database (genealogy).
>>
>> 3) Typically I create .dll's that serve as a library (WPF Custom
>> Control Library) ... easy to use for different programs.
>>
>> 4) For example, I have an Excel .dll library (uses Excel as a
>> database).  When the program runs the first time using this .dll
>> library, it creates the Excel file along with multiple sheets.
>>
>> 5) I'd like to create a similar .dll for an SQLite library.  The
>> program that uses this .dll is a simple WPF program that uses the .dll
>> class name to access the functions.
>>
>> With this info, which option would you recommend?
>>
>>> On Sun, Feb 19, 2017 at 9:45 PM, Barry Smith  wrote:
>>> Strange, I replied to this earlier... Perhaps my messages are not getting 
>>> through.
>>>
>>> You cannot include a .c file for compilation in a c# project. You'd have to 
>>> do use a separate DLL and do some pinvoke stuff to get to the raw SQLite 
>>> interface, but in my opinion you're better off using the system.data.sqlite 
>>> wrapper. If you need the speed and power of the raw interface, you probably 
>>> need to drop out of an interpreted and managed language (c#) too...
>>>
>>> You don't need the entity framework (EF) to run system.data.sqlite. That is 
>>> an object relational mapper (ORM) that uses a lot of fancy reflection to 
>>> make data access a little easier* (until you get stung by it) and a lot 
>>> slower. EF is developed my Microsoft, although SQLite must provide some 
>>> input to make it work with its syntax. You should be able to remove the 
>>> entity framework dependencies from your project and still compile with no 
>>> issues. Try a complete rebuild / clean compile to try get rid of the 
>>> unnecessary dlls.
>>>
>>> *whether an ORM actually makes data access easier is debatable, they 
>>> basically allow you to write your data access queries in LINQ rather than 
>>> SQL, and automatically instansiate c# objects for each line in the results. 
>>> I find SQL easier...
>>>
 On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis  wrote:

 Sorry for the slow response.

 My code is in C#.  I don't know if the amalgamation source code in C
 can be compiled so it is compatible with C#.

 If it can, I'd be interested in details.  Thanks!

> On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>
>
>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>>
>>> On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
>>>
>>> You can even checkout the latest commits via SVN
>>
>> There’s a Subversion mirror of the official Fossil code repository for
>> SQLite?
>
>
> Apologies, force of habit nomenclature. Have fallen to calling any 
> Software
> Versioning system just 'SVN' for short. I did of course mean for it to be
> checked out via Fossil.
>
>>https://goo.gl/KzLcV8
>>
>> (Excuse the shortener, it’s a raly long URL.)
>>
>> I could give you that Zip file link, but I suspect it’s purposely not
>> 

Re: [sqlite] SQLite Options

[Barry Smith]

I would use system.data.sqlite in that situation.

But I would also say it depends on what you already have written, and what your 
strengths are. I am under the impression from your first email that you already 
have something written using system.data.sqlite. i.e. Using the class 
System.Data.SQLite.SQLiteConnection to create a connection to the db, then 
using the methods of that to manipulate the db or extract data from it. Have I 
assumed wrong?

If I am wrong, and you have yet to start writing anything, I would still 
recommend using system.data.sqlite. Only if you particularly like LINQ over SQL 
and you are prepared to learn the caveats of the entity framework would I 
recommend that.

Note that if you're using system.data.sqlite you will ultimately produce a few 
dlls that must be distributed together:
 - your custom library, which contains the code you've written
 - System.Data.Sqlite.dll, which contains the wrapper to make an interface to 
access SQLite in a more dotNet friendly manner
 - x64\sqlite.interop.dll
 - x86\sqlite.interop.dll
The last two contain the 'raw' SQLite library (for either 32 or 64 bit systems).

You should not need the other libraries for a simple application. If you find 
that visual studio is placing them in your project's output directory, check if 
they are listed as a reference and try to remove them then recompile.

> On 20 Feb 2017, at 1:05 PM, Clyde Eisenbeis  wrote:
> 
> Thanks for the clarification.  In my case:
> 
> 1) Speed is not an issue.  Size is not an issue.
> 
> 2) This is a personal use database (genealogy).
> 
> 3) Typically I create .dll's that serve as a library (WPF Custom
> Control Library) ... easy to use for different programs.
> 
> 4) For example, I have an Excel .dll library (uses Excel as a
> database).  When the program runs the first time using this .dll
> library, it creates the Excel file along with multiple sheets.
> 
> 5) I'd like to create a similar .dll for an SQLite library.  The
> program that uses this .dll is a simple WPF program that uses the .dll
> class name to access the functions.
> 
> With this info, which option would you recommend?
> 
>> On Sun, Feb 19, 2017 at 9:45 PM, Barry Smith  wrote:
>> Strange, I replied to this earlier... Perhaps my messages are not getting 
>> through.
>> 
>> You cannot include a .c file for compilation in a c# project. You'd have to 
>> do use a separate DLL and do some pinvoke stuff to get to the raw SQLite 
>> interface, but in my opinion you're better off using the system.data.sqlite 
>> wrapper. If you need the speed and power of the raw interface, you probably 
>> need to drop out of an interpreted and managed language (c#) too...
>> 
>> You don't need the entity framework (EF) to run system.data.sqlite. That is 
>> an object relational mapper (ORM) that uses a lot of fancy reflection to 
>> make data access a little easier* (until you get stung by it) and a lot 
>> slower. EF is developed my Microsoft, although SQLite must provide some 
>> input to make it work with its syntax. You should be able to remove the 
>> entity framework dependencies from your project and still compile with no 
>> issues. Try a complete rebuild / clean compile to try get rid of the 
>> unnecessary dlls.
>> 
>> *whether an ORM actually makes data access easier is debatable, they 
>> basically allow you to write your data access queries in LINQ rather than 
>> SQL, and automatically instansiate c# objects for each line in the results. 
>> I find SQL easier...
>> 
>>> On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis  wrote:
>>> 
>>> Sorry for the slow response.
>>> 
>>> My code is in C#.  I don't know if the amalgamation source code in C
>>> can be compiled so it is compatible with C#.
>>> 
>>> If it can, I'd be interested in details.  Thanks!
>>> 
 On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
 
 
>> On 2017/02/18 12:45 AM, Warren Young wrote:
>> 
>> On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
>> 
>> You can even checkout the latest commits via SVN
> 
> There’s a Subversion mirror of the official Fossil code repository for
> SQLite?
 
 
 Apologies, force of habit nomenclature. Have fallen to calling any Software
 Versioning system just 'SVN' for short. I did of course mean for it to be
 checked out via Fossil.
 
>https://goo.gl/KzLcV8
> 
> (Excuse the shortener, it’s a raly long URL.)
> 
> I could give you that Zip file link, but I suspect it’s purposely not
> being published to avoid load on the SQLite repository server caused by 
> bots
> repeatedly requesting Zip files and tarballs.
 
 
 The bots can read goo links nowadays. ;)
 
> Using Fossil is far more efficient than downloading Zip archives, but as I
> keep getting reminded in my own Fossil-hosted public project, some people
> 

Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

Thanks for the clarification.  In my case:

1) Speed is not an issue.  Size is not an issue.

2) This is a personal use database (genealogy).

3) Typically I create .dll's that serve as a library (WPF Custom
Control Library) ... easy to use for different programs.

4) For example, I have an Excel .dll library (uses Excel as a
database).  When the program runs the first time using this .dll
library, it creates the Excel file along with multiple sheets.

5) I'd like to create a similar .dll for an SQLite library.  The
program that uses this .dll is a simple WPF program that uses the .dll
class name to access the functions.

With this info, which option would you recommend?

On Sun, Feb 19, 2017 at 9:45 PM, Barry Smith  wrote:
> Strange, I replied to this earlier... Perhaps my messages are not getting 
> through.
>
> You cannot include a .c file for compilation in a c# project. You'd have to 
> do use a separate DLL and do some pinvoke stuff to get to the raw SQLite 
> interface, but in my opinion you're better off using the system.data.sqlite 
> wrapper. If you need the speed and power of the raw interface, you probably 
> need to drop out of an interpreted and managed language (c#) too...
>
> You don't need the entity framework (EF) to run system.data.sqlite. That is 
> an object relational mapper (ORM) that uses a lot of fancy reflection to make 
> data access a little easier* (until you get stung by it) and a lot slower. EF 
> is developed my Microsoft, although SQLite must provide some input to make it 
> work with its syntax. You should be able to remove the entity framework 
> dependencies from your project and still compile with no issues. Try a 
> complete rebuild / clean compile to try get rid of the unnecessary dlls.
>
> *whether an ORM actually makes data access easier is debatable, they 
> basically allow you to write your data access queries in LINQ rather than 
> SQL, and automatically instansiate c# objects for each line in the results. I 
> find SQL easier...
>
>> On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis  wrote:
>>
>> Sorry for the slow response.
>>
>> My code is in C#.  I don't know if the amalgamation source code in C
>> can be compiled so it is compatible with C#.
>>
>> If it can, I'd be interested in details.  Thanks!
>>
>>> On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>>>
>>>
 On 2017/02/18 12:45 AM, Warren Young wrote:

> On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
>
> You can even checkout the latest commits via SVN

 There’s a Subversion mirror of the official Fossil code repository for
 SQLite?
>>>
>>>
>>> Apologies, force of habit nomenclature. Have fallen to calling any Software
>>> Versioning system just 'SVN' for short. I did of course mean for it to be
>>> checked out via Fossil.
>>>
 https://goo.gl/KzLcV8

 (Excuse the shortener, it’s a raly long URL.)

 I could give you that Zip file link, but I suspect it’s purposely not
 being published to avoid load on the SQLite repository server caused by 
 bots
 repeatedly requesting Zip files and tarballs.
>>>
>>>
>>> The bots can read goo links nowadays. ;)
>>>
 Using Fossil is far more efficient than downloading Zip archives, but as I
 keep getting reminded in my own Fossil-hosted public project, some people
 just refuse to install and use anything they don’t absolutely have to.  
 It’s
 six easy steps, but apparently that’s too many for some.
>>>
>>>
>>> Agreed, and what is more sad is that Fossil is so much better at actual
>>> "Version-Control" (as opposed to making sharing code easiest). If we could
>>> get the rest of the World to rather Fossil, everybody wins. (I can already
>>> hear Linus clutching his chest and breathing erratically!)
>>>
>>>
>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Barry Smith]

Strange, I replied to this earlier... Perhaps my messages are not getting 
through.

You cannot include a .c file for compilation in a c# project. You'd have to do 
use a separate DLL and do some pinvoke stuff to get to the raw SQLite 
interface, but in my opinion you're better off using the system.data.sqlite 
wrapper. If you need the speed and power of the raw interface, you probably 
need to drop out of an interpreted and managed language (c#) too...

You don't need the entity framework (EF) to run system.data.sqlite. That is an 
object relational mapper (ORM) that uses a lot of fancy reflection to make data 
access a little easier* (until you get stung by it) and a lot slower. EF is 
developed my Microsoft, although SQLite must provide some input to make it work 
with its syntax. You should be able to remove the entity framework dependencies 
from your project and still compile with no issues. Try a complete rebuild / 
clean compile to try get rid of the unnecessary dlls.

*whether an ORM actually makes data access easier is debatable, they basically 
allow you to write your data access queries in LINQ rather than SQL, and 
automatically instansiate c# objects for each line in the results. I find SQL 
easier...

> On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis  wrote:
> 
> Sorry for the slow response.
> 
> My code is in C#.  I don't know if the amalgamation source code in C
> can be compiled so it is compatible with C#.
> 
> If it can, I'd be interested in details.  Thanks!
> 
>> On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>> 
>> 
>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>> 
 On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
 
 You can even checkout the latest commits via SVN
>>> 
>>> There’s a Subversion mirror of the official Fossil code repository for
>>> SQLite?
>> 
>> 
>> Apologies, force of habit nomenclature. Have fallen to calling any Software
>> Versioning system just 'SVN' for short. I did of course mean for it to be
>> checked out via Fossil.
>> 
>>> https://goo.gl/KzLcV8
>>> 
>>> (Excuse the shortener, it’s a raly long URL.)
>>> 
>>> I could give you that Zip file link, but I suspect it’s purposely not
>>> being published to avoid load on the SQLite repository server caused by bots
>>> repeatedly requesting Zip files and tarballs.
>> 
>> 
>> The bots can read goo links nowadays. ;)
>> 
>>> Using Fossil is far more efficient than downloading Zip archives, but as I
>>> keep getting reminded in my own Fossil-hosted public project, some people
>>> just refuse to install and use anything they don’t absolutely have to.  It’s
>>> six easy steps, but apparently that’s too many for some.
>> 
>> 
>> Agreed, and what is more sad is that Fossil is so much better at actual
>> "Version-Control" (as opposed to making sharing code easiest). If we could
>> get the rest of the World to rather Fossil, everybody wins. (I can already
>> hear Linus clutching his chest and breathing erratically!)
>> 
>> 
>> 
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

Sorry for the slow response.

My code is in C#.  I don't know if the amalgamation source code in C
can be compiled so it is compatible with C#.

If it can, I'd be interested in details.  Thanks!

On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>
>
> On 2017/02/18 12:45 AM, Warren Young wrote:
>>
>> On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
>>>
>>> You can even checkout the latest commits via SVN
>>
>> There’s a Subversion mirror of the official Fossil code repository for
>> SQLite?
>
>
> Apologies, force of habit nomenclature. Have fallen to calling any Software
> Versioning system just 'SVN' for short. I did of course mean for it to be
> checked out via Fossil.
>
>>  https://goo.gl/KzLcV8
>>
>> (Excuse the shortener, it’s a raly long URL.)
>>
>> I could give you that Zip file link, but I suspect it’s purposely not
>> being published to avoid load on the SQLite repository server caused by bots
>> repeatedly requesting Zip files and tarballs.
>
>
> The bots can read goo links nowadays. ;)
>
>> Using Fossil is far more efficient than downloading Zip archives, but as I
>> keep getting reminded in my own Fossil-hosted public project, some people
>> just refuse to install and use anything they don’t absolutely have to.  It’s
>> six easy steps, but apparently that’s too many for some.
>
>
> Agreed, and what is more sad is that Fossil is so much better at actual
> "Version-Control" (as opposed to making sharing code easiest). If we could
> get the rest of the World to rather Fossil, everybody wins. (I can already
> hear Linus clutching his chest and breathing erratically!)
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[R Smith]

On 2017/02/18 12:45 AM, Warren Young wrote:

On Feb 17, 2017, at 7:32 AM, R Smith  wrote:

You can even checkout the latest commits via SVN

There’s a Subversion mirror of the official Fossil code repository for SQLite?


Apologies, force of habit nomenclature. Have fallen to calling any 
Software Versioning system just 'SVN' for short. I did of course mean 
for it to be checked out via Fossil.



 https://goo.gl/KzLcV8

(Excuse the shortener, it’s a raly long URL.)

I could give you that Zip file link, but I suspect it’s purposely not being 
published to avoid load on the SQLite repository server caused by bots 
repeatedly requesting Zip files and tarballs.


The bots can read goo links nowadays. ;)


Using Fossil is far more efficient than downloading Zip archives, but as I keep 
getting reminded in my own Fossil-hosted public project, some people just 
refuse to install and use anything they don’t absolutely have to.  It’s six 
easy steps, but apparently that’s too many for some.


Agreed, and what is more sad is that Fossil is so much better at actual 
"Version-Control" (as opposed to making sharing code easiest). If we 
could get the rest of the World to rather Fossil, everybody wins. (I can 
already hear Linus clutching his chest and breathing erratically!)



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Warren Young]

On Feb 17, 2017, at 7:32 AM, R Smith  wrote:
> 
> You can even checkout the latest commits via SVN

There’s a Subversion mirror of the official Fossil code repository for SQLite?

I tried to search the web for it, but since Subversion uses SQLite internally 
to manage its own code repositories, I get pages and pages of irrelevant 
results.

As far as I know, if you want the current tip-of-trunk source code to SQLite3, 
you need to either clone it via Fossil or work out how to construct a Zip URL 
per

https://goo.gl/KzLcV8

(Excuse the shortener, it’s a raly long URL.)

I could give you that Zip file link, but I suspect it’s purposely not being 
published to avoid load on the SQLite repository server caused by bots 
repeatedly requesting Zip files and tarballs.

Using Fossil is far more efficient than downloading Zip archives, but as I keep 
getting reminded in my own Fossil-hosted public project, some people just 
refuse to install and use anything they don’t absolutely have to.  It’s six 
easy steps, but apparently that’s too many for some.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Stephen Chrzanowski]

(A little bit off topic)

On Fri, Feb 17, 2017 at 9:32 AM, R Smith  wrote:

> . though some wrappers exist for almost all programming languages and
> they are relatively easy to use too - *but for brute speed and control,
> use the API directly.*
>

Ever since I found SQLite3 and a decent wrapper that does exactly what I've
needed it to do, I've ALWAYS wanted to do a direct port of the Amalgamation
into a Delphi/Pascal unit so I can just include it and have the
functionality built in, period, built by the Pascal engine.  However, when
I last looked at the Amalgamation source code, it was 4 meg in size.  It'd
take me a while :]

One of these days.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Barry Smith]

System.Data.SQLite is the package you want if you just want a .Net style (i.e. 
Using the standard .net db interfaces) wrapper around SQLite. You can find it 
on NuGet.

The entity framework is a library that maps database entries and relations to 
OOP style objects. Look up object relational mapping (ORM). It's a bit of a 
monster that uses a lot of reflection. It can make some tasks easier, but it's 
also very easy to get stung by it. I would not recommend it for any time you 
need performance, or to deal with even moderate record counts. Although the 
entity framework is compatible with SQLite and system.data.sqlite, it is not 
specific to this dbms - it's a data access layer developed by Microsoft for 
general db access. You do not need it to use SQLite.

Have you tried to remove the reference to the entity framework then performed a 
clean build?

Ps this list strips attachments, so I can't see exactly what you've highlighted.

> On 16 Feb 2017, at 5:40 PM, Clyde Eisenbeis  wrote:
> 
> I started writing SQLite code about two years ago (Visual Studio 2013,
> C#, WPF) ... with a significant delay, since then, because of a
> physical move.
> 
> The code is written for a specific use on my computer ... no other users.
> 
> SQLite was chosen so my sons could eventually install this program on
> their computer ... no database needs to be installed ... no other
> installation required.
> 
> I don't recall the actions taken then, but I do see quite a few
> additional files (EntityFramework.dll, EntityFramework.SqlServer.dll,
> etc.) as references ... see attachment.
> 
> Is there an SQLite version that is comprised of fewer dlls, etc.? ...
> Perhaps SQLite3?
> 
> Clyde
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[R Smith]

On 2017/02/17 4:11 PM, Clyde Eisenbeis wrote:

Is SQLite Version 3 the same as SQLite3? ...
http://www.sqlite.org/download.html.


Yes.
You have been using SQLite3 through a wrapper, a good one by the way, 
but the core API comes as a single C file which can be compiled into 
your program directly and then you can use the API functions from there, 
all of which are well documented. This is the normal (and arguable the 
best) way to use SQLite3, though some wrappers exist for almost all 
programming languages and they are relatively easy to use too - but for 
brute speed and control, use the API directly.


You can even checkout the latest commits via SVN if you are wanting to 
be on the cutting edge or testing new features - but usually downloading 
the latest release is sufficient for normal use.


Another option is linking to a library, which is much the same like 
using the API directly from the compiled-in file, except you first have 
to link against it, such as the downloadable DLL for windows or the 
libraries for Linux, Android, OSX etc. All of these options, from the 
full amalgamation to the .NET wrapper you've been using to the dynamic 
linked libraries and even a command line interface program and the 
documentation to use the API are all downloadable from:

http://www.sqlite.org/download.html

Whichever flavour you prefer - and you can even roll your own by 
compiling any of the above with the latest sources yourself. :)


The API usage documentation can also be found online here:
http://www.sqlite.org/cintro.html

And of course, any questions you may have, this helpful forum will 
supply with gusto.


Good luck!
Ryan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Clyde Eisenbeis]

Is SQLite Version 3 the same as SQLite3? ...
http://www.sqlite.org/download.html.

On Thu, Feb 16, 2017 at 3:01 PM, Simon Slavin  wrote:
>
> On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis  wrote:
>
>> Is there an SQLite version that is comprised of fewer dlls, etc.? ...
>> Perhaps SQLite3?
>
> If you’re writing C or C++ code all you need is the amalgamation source code 
> files from the SQLite3 site.  You compile them into your program.  No DLLs 
> needed at all.
>
> The need for DLLs comes when you need a 'shim' to allow your favourite 
> programming language to be able to call the SQLite API functions.  Even then 
> you can do without them if your favourite programming language has the 
> ability to call C functions directly.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

[Simon Slavin]

On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis  wrote:

> Is there an SQLite version that is comprised of fewer dlls, etc.? ...
> Perhaps SQLite3?

If you’re writing C or C++ code all you need is the amalgamation source code 
files from the SQLite3 site.  You compile them into your program.  No DLLs 
needed at all.

The need for DLLs comes when you need a 'shim' to allow your favourite 
programming language to be able to call the SQLite API functions.  Even then 
you can do without them if your favourite programming language has the ability 
to call C functions directly.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users