SQLite Options

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

SQLite Options

Clyde Eisenbeis
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Simon Slavin-3

On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

>
> On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis <[hidden email]> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Barry Smith
In reply to this post by Clyde Eisenbeis
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 <[hidden email]> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Stephen Chrzanowski
In reply to this post by R Smith
(A little bit off topic)

On Fri, Feb 17, 2017 at 9:32 AM, R Smith <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Delphi unit (was: SQLite Options)

Clemens Ladisch
Stephen Chrzanowski wrote:
> 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.... :]

Delphi can directly link to .obj files created by the Borland C compiler.
(And BCC 5.5.1 is free.)  See this thread:
http://sqlite.1065341.n5.nabble.com/latest-sqlite-3-with-Delphi-5-professional-td73388.html


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Delphi unit (was: SQLite Options)

R Smith
In reply to this post by Stephen Chrzanowski

On 2017/02/17 5:17 PM, Stephen Chrzanowski wrote:

> (A little bit off topic)
>
> On Fri, Feb 17, 2017 at 9:32 AM, R Smith <[hidden email]> 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.....

You don't need a Port, just a good translation.  A port won't be
update-able, an API translation would be. Best of this is to link a DLL
which means the C code is all compiled in the DLL and Delphi merely maps
the DLL using C calling conventions, easy mode - not to mention the boon
of being able to swap out DLLs easily without recompiling the parent exe.

Prefer not to link? Delphi can compile C files directly into .obj files
which you can link against at compile time (so no external libraries),
but then you lose the option of swapping out newer DLLs and you need to
re-compile against the newest C files. The Delphi system might be
expensive, but the compilers are free (at least some versions of it).

Another option is a good Delphi wrapper that makes a database connection
into an object you can use as needed, but without the fat.

Others and myself have, over the years, created very good versions of
these for Delphi - you can see them in action in many products, most
notably perhaps SQLitespeed (http://www.rifin.co.za/software/sqlc/), and
you are welcome to have the code - they are free and up to date,
supporting all versions (but only tested up to XE8). Poke me off-list if
you would like them.

What you definitely don't want to do is Porting the code to a delphi
language (C++, Obj Pascal etc). That will require re-inventing the wheel
(or at least re-manufacturing it a bit) with every release.

Cheers,
Ryan



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Delphi unit (was: SQLite Options)

Stephen Chrzanowski
@Clemmins;

I'll read over that a bit more carefully, and see if there are any hints on
HOW-TO in there.  I'm using the free version of Berlin ATM, and when I win
a small lottery, I'd love to upgrade as I REALLllly miss the code reformat
functionality of previous versions.  (Previous employer gave me, directly,
a license for D5 and 7 -- Can't tell ya in how many places I've got those
codes stored. ;) )

@Ryan;

As a developer, who's only done code always for for myself, previous
employer for in-shop work only, and a few friends, I'm in both camps for
"Use DLLs" and "Single EXEs".  I agree with both sides of the argument,
but, my mind pertaining to the distribution of SQLite3 DLLs by 3rd parties
leans me towards the Single EXE methodology, at least for my applications.
Even my personal rig has been (temporarily) messed up due to a 3rd party
app that decided its version of the SQLite library is more important than
what existed before.  Knowing that capability exists for 3rd parties to
steam roll a working machine into a partially working machine, this event
has affected how I build and stage things in a couple of ways, but that's
another story.

When performing upgrades to my software, and distributing it, typically, my
EXE code is being updated as well anyways.  If the DLL has to be updated as
well, well, then, that's great, and that DLL would be part of the
distribution anyways.  I understand that for MASSIVE application packages,
where many EXEs rely on single DLLs, yeah, then DLL methodology is probably
the way to go, as a small 50k file to fix a problem for many applications
in the package, makes perfect sense.  However, working with already a
single do-everything-it-needs-to-do-under-one-roof kind of application, I'm
able to see the advantages on BOTH sides of the fence.  Due to the unknown
recipient machines, in regards to availability of SQLite3 being present at
all, the correct version that supports my code, and other varying details
that I'm overlooking about an unknown entity, having what I know works in
one single source, and it dealing with everything internally makes more
sense to me.  Sometimes, I even build in the JPGs for icons, mouse cursors,
sounds, and all that DIRECTLY into the EXE, as I don't want people to
change a mouse click into a train horn or whatever.  (As fun as that is ;) )

Don't get me wrong.  Merritt to BOTH sides of the coin.  Right now, I just
don't have the option of a truly single EXE with baked in DB engine
capabilities, and I know that I miss it.  If I can figure out the OBJ
methodology, and get the wrapper I use (
http://www.itwriting.com/blog/articles/a-simple-delphi-wrapper-for-sqlite-3)
to work with the OBJ or DLL based on build conditions, I'm all for it.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Warren Young
In reply to this post by R Smith
On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

R Smith


On 2017/02/18 12:45 AM, Warren Young wrote:
> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

>
>
> On 2017/02/18 12:45 AM, Warren Young wrote:
>>
>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>>
>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>>>
>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>>>>>
>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>>>> [hidden email]
>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>>>>>>
>>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>>>>> [hidden email]
>>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>> _______________________________________________
>>>> sqlite-users mailing list
>>>> [hidden email]
>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Barry Smith
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >>>>>
> >>>>>
> >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
> >>>>>>>
> >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
> >>>>> [hidden email]
> >>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>>> _______________________________________________
> >>>> sqlite-users mailing list
> >>>> [hidden email]
> >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>> _______________________________________________
> >>> sqlite-users mailing list
> >>> [hidden email]
> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >> _______________________________________________
> >> sqlite-users mailing list
> >> [hidden email]
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >>>>>
>> >>>>>
>> >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>> >>>>>>>
>> >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>> >>>>> [hidden email]
>> >>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> >>>> _______________________________________________
>> >>>> sqlite-users mailing list
>> >>>> [hidden email]
>> >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> >>> _______________________________________________
>> >>> sqlite-users mailing list
>> >>> [hidden email]
>> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> >> _______________________________________________
>> >> sqlite-users mailing list
>> >> [hidden email]
>> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> > _______________________________________________
>> > sqlite-users mailing list
>> > [hidden email]
>> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite Options

Clyde Eisenbeis
in my SQLite.dll library program.

On Tue, Feb 21, 2017 at 2:42 PM, Clyde Eisenbeis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>>> >>>>>>>
>>> >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[hidden email]> 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 reeeealy 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
>>> >>>>> [hidden email]
>>> >>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> >>>> _______________________________________________
>>> >>>> sqlite-users mailing list
>>> >>>> [hidden email]
>>> >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> >>> _______________________________________________
>>> >>> sqlite-users mailing list
>>> >>> [hidden email]
>>> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> >> _______________________________________________
>>> >> sqlite-users mailing list
>>> >> [hidden email]
>>> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> > _______________________________________________
>>> > sqlite-users mailing list
>>> > [hidden email]
>>> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users