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
