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
