You could look at SQL Server compact edition - only needs a .NET DLL - but with some restrictions:
https://msdn.microsoft.com/en-gb/library/bb896140.aspx>Gotcha. Makes sense. Yes, I have wondered about the distribution issue for SSE. Haven't really seen a good methodology for a simple unattended install and config of SSE. Fortunately, at this point, this is not something I have had to do.
>
>Thx. Bill
>
>>Depends on what you need to do. SqLite is small compact and fast and works well for local only data. SQL Express is well SQL Server. You get all the benefits of a real server based engine including transaction security, profiling, backups, all the SQL tooling etc. But it's big and is pain to install if you need to distribute it.
>>
>>Right tool for the job.
>>
>>+++ Rick ---
>>
>>>Hey Rick,
>>>
>>>Then are you recommending SqlLite over SQL Server Express? I have used SSE locally for quite a while and found it quite functional and usable.
>>>
>>>Bill
>>>
>>>>SqLite is a great local data engine where you essentially have 'exclusive' use, but it's not a good choice for network for the same reason VFP data is not good for network data in that there's no server that feeds you just the result data - standard ISASM which is not very efficient as it has to pull the entire database (or indexes) across the wire for queries which causes big churn on the network.
>>>>
>>>>SqLite also locks the entire tables for updates so for multi-user updates it's not a good choice.
>>>>
>>>>For local DB access it's hard to beat though - it's very fast too. Recently added some logging to a very high perf app and we were seeing close to 50,000 inserts.
>>>>
>>>>+++ Rick ---
>>>>
>>>>
>>>>
>>>>>Hi Alejandro,
>>>>>
>>>>>I am moving my stuff out of VFP as well. Not fully sure about the end platform, some sort of *ython (plain old C-based Python, Ironpython on the MS platform, Jython or a js-based one, should that arise). The only sure thing to me is the data handling on the next version: SQLITE.
>>>>>
>>>>>Both as a persistent layer at runtime (yep IN-MEMORY... That does not preclude using more efficient data structures when needed but I am bought on SQL) and as persistent storage (yep as an "Application file format" à la VFP but on a wider multi-table basis). Why? It's speedy enough for most usages. You can read:
>>>>>
>>>>>
https://www.sqlite.org/about.html>>>>>
>>>>>And specifically:
>>>>>
>>>>>
https://www.sqlite.org/whentouse.html>>>>>
>>>>>A database engine for this.... Quite a number of products do that (including browsers and widely spread apps). The only thing that would keep me outside of the comfortable sqlite bandwagon:
>>>>>1- such a limited need that can be catered for with ini file (or a minimalist json-like format),
>>>>>2- an alternative engine that would be more MS-OS friendly. Sqlite is OS-agnostic.
>>>>>
>>>>>My 0.2 cents
>>>>>
>>>>>Daniel
