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 <smith.bar...@gmail.com> 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 <cte...@gmail.com> 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 <smith.bar...@gmail.com>
>> 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 <cte...@gmail.com> 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 <smith.bar...@gmail.com>
>> 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 <cte...@gmail.com> 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 <rsm...@rsweb.co.za> wrote:
>> >>>>>
>> >>>>>
>> >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote:
>> >>>>>>>
>> >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <rsm...@rsweb.co.za> 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
>> >>>>> 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
>> > _______________________________________________
>> > 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
