Hey Thomas,

Understood. I was thinking primarily of the local, single-user scenario. Several years ago we did have a desktop application that was deployed to several sites using SQL Server Express as a multi-user backend and it performed quite well but the user load was small in all cases.

I was just wondering about the comparison of SSE with SqlLite since I have not used SqlLite.

Bill

>IMO opinion SQLite use cases are more similar to those the SQL Server Compact Edition is intended for - local data handling similar to an embedded database.
>The write-locks Rick mentions do not matter that much if happening only at one machine from one or a few processes. Hitting SQLite behind a webserver from a humongous user base with inset or update commands is not the best use case, read only is usually good enough.
>
>
>>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.
>>
>>>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