LocalDB Tips for embedded installation

  • Folks,
    Im a DBA/Developer in small team, just 2 of us. We use SQL Server for all db storage.
    We have been developing asp.net applications for over a decade, but we recently got an urgent request to create a desktop version of one of our applications which needs to have a database local to the actual desktop machine. 
    We have a lot of reliable plumbing in our web application framework in terms of ORM and DI etc, and the timelines are ridiculous, so we have decided not to risk re-engineering to another more local install friendly database like SQLLite.

    We are hoping to use a SQL Server 2016 Localdb on the desktop machine, installing this as part of the desktop application (WPF based) install. Part of the reason we are thinking of going to localdb is that it lessens the installation footprint of our users, who are not I.T. proficient. We are concerned that having a SQL Express instance running on the machine would only give us something else to worry about. Our clients are in disparate locations across europe, We have extremely limited post-install support options.
    The data is PHI laden and we have no remote access to these machines once installed. Apparently this is down to European HIPAA regulations and the environment itself.

    I am quite worried about unforeseen problems with Localdb arising after install. Problems with permissions etc.
    Can anyone advise me here on how I can bulletproof a Localdb installation context such as this, especially as regards permissions?

  • mick L - Saturday, February 4, 2017 3:32 AM

    Folks,
    Im a DBA/Developer in small team, just 2 of us. We use SQL Server for all db storage.
    We have been developing asp.net applications for over a decade, but we recently got an urgent request to create a desktop version of one of our applications which needs to have a database local to the actual desktop machine. 
    We have a lot of reliable plumbing in our web application framework in terms of ORM and DI etc, and the timelines are ridiculous, so we have decided not to risk re-engineering to another more local install friendly database like SQLLite.

    We are hoping to use a SQL Server 2016 Localdb on the desktop machine, installing this as part of the desktop application (WPF based) install. Part of the reason we are thinking of going to localdb is that it lessens the installation footprint of our users, who are not I.T. proficient. We are concerned that having a SQL Express instance running on the machine would only give us something else to worry about. Our clients are in disparate locations across europe, We have extremely limited post-install support options.
    The data is PHI laden and we have no remote access to these machines once installed. Apparently this is down to European HIPAA regulations and the environment itself.

    I am quite worried about unforeseen problems with Localdb arising after install. Problems with permissions etc.
    Can anyone advise me here on how I can bulletproof a Localdb installation context such as this, especially as regards permissions?

    Mick - It's been a while since you posted this and I'd like to know whether the project went forward and do you have any advice for others with similar requirements?  I am also developing a WPF application with a SQL LocalDB and am researching how to manage database schema changes as future releases are deployed.  I'm considering using InstallShield and somehow running a custom script to update the database.  I appreciate any feedback you might have from your project.

  • bbop - Wednesday, November 29, 2017 8:44 AM

    mick L - Saturday, February 4, 2017 3:32 AM

    Folks,
    Im a DBA/Developer in small team, just 2 of us. We use SQL Server for all db storage.
    We have been developing asp.net applications for over a decade, but we recently got an urgent request to create a desktop version of one of our applications which needs to have a database local to the actual desktop machine. 
    We have a lot of reliable plumbing in our web application framework in terms of ORM and DI etc, and the timelines are ridiculous, so we have decided not to risk re-engineering to another more local install friendly database like SQLLite.

    We are hoping to use a SQL Server 2016 Localdb on the desktop machine, installing this as part of the desktop application (WPF based) install. Part of the reason we are thinking of going to localdb is that it lessens the installation footprint of our users, who are not I.T. proficient. We are concerned that having a SQL Express instance running on the machine would only give us something else to worry about. Our clients are in disparate locations across europe, We have extremely limited post-install support options.
    The data is PHI laden and we have no remote access to these machines once installed. Apparently this is down to European HIPAA regulations and the environment itself.

    I am quite worried about unforeseen problems with Localdb arising after install. Problems with permissions etc.
    Can anyone advise me here on how I can bulletproof a Localdb installation context such as this, especially as regards permissions?

    Mick - It's been a while since you posted this and I'd like to know whether the project went forward and do you have any advice for others with similar requirements?  I am also developing a WPF application with a SQL LocalDB and am researching how to manage database schema changes as future releases are deployed.  I'm considering using InstallShield and somehow running a custom script to update the database.  I appreciate any feedback you might have from your project.

    Hello there,
    We decided against going with LocalDb. we realized that different folks could potentially Login to windows and that might cause problems with the per-user model. We just went with a SQL Express install with pre-configuration set using Wix. There you can set all manner of switches to deal with installing .Net Framework, dealing with 32/64 bit environments and setting up SA etc. This project has not gone live yet; it has been hibernating for the last few months.
    Regarding SQL Database updates we used a library called DBUP  https://dbup.github.io/ to create little patches using c# code. I have attached an example of its use

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply