Question

I am considering adding LocalDB for data storage to my application.

Background:

1) My Application has 2 parts.
a. A Desktop Client. (Running Under the user that logged into the computer)
b. NT Service. (Running as Local System)

NT Service:
1) Make web service calls to our back end server for client specific settings and configuration options.
2) Upload client created records.

Desktop App:
1) Load the settings downloaded by the NT Service and run according to those settings.
2) Create client records.

LocalDB seem like a good fit here but can both of these items access the LOCALDB at the same time? After some investigation online it looks like a LOCALDB shared instance may be possible. However does that mean the NT Service would have to keep the LOCALDB connection alive all the time?

Answer 1

Having done a very similar deployment to what you have described, yes this can be done. However I would strongly advise against it.

Some thoughts:

1. LocalDB ‘instances‘ require the user profile be loaded. The only use profile that is always loaded is Local System aka the NT Authority\SYSTEM account.
2. Only the owner of the ‘instance‘ can start or stop it. The ‘automagic‘ instance can be set to ignore the auto-showdown timeout, but it still has to be started atleast once. I solved this by creating a windows task that launched a bootstrapper that shelled out ‘sqllocaldb start v11.0‘ on boot. Windows Tasks execute with ‘Below Normal‘ process priority so the launched bootstrapper actually boosted the SQLEnv.exe priority to high for my use case.
3. Assuming you go with NT Authority\SYSTEM being the instance profile, using something like SQL Management Studio would likely require PsExec on the system. This is a security risk because it gives you interactive access to a proccess that runs as Local System. Don’t do it.
4. We used groups for access to our client part so we grant access for those groups to the actual database/instance. Without that it is damn near impossible to grant new users access to the instance/database.

Do you really need a database or could the thick client write out a file to a specific location for each record that the service then inspects(or builds a buffer) and sends on its way?

Another alternative is to remove the NT Service and make its functionality the a part of the Client start up process. Why have a long running process that constantly checks for config changes and only pushes data if the user is actively using the system? Assuming you don’t have requirements/an existing system.