Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>For deploying at the client, I would rethink the strategy for its local database. Problem is that, as I understood, you're using SQL Server too on each and every client with a local .mdf file, which I consider more of a problem than a solution, since it works like any normal DB server but installed locally, with all the headaches it produces. And since clients should not receive external connections (correct me if I'm wrong here) a full blown server would be an overkill. My idea is to choose a different DB engine for the client-side:</p> <ul> <li><a href="http://www.sqlite.org/" rel="nofollow">SQLite</a> would be my prime choice. It's an embedded DB engine that's just a single DLL in its most minimal form, and a few more with its .NET wrappers. It stores data in a file of your choice and access it with standard SQL language. Deployment would be as easy as copy a few more libraries into your installation folder, which fits your desired next/next/next install procedure. The drawback is that it support only a subset of the features that SQL Server has, which may or may nor be a problem for your particular case.</li> <li>SQL Server Compact Edition is very similar, running totally local without a real server and accessing a local file. Its features are somewhat similar to SQLite, and still well below from SQL Server, but again for a local copy it seems enough for me. Deployment again is simply copying a bunch of files to the program folder. <a href="http://msdn.microsoft.com/en-us/library/aa983326%28v=vs.90%29.aspx" rel="nofollow">This article</a> has some hints for installing this DB engine</li> <li>If you need the full power of a real SQL Server, an alternative option would be to make use of a new feature of SQL 2012 called "LocalDB". It's basically the same DB engine from SQL Express, but it runs on-demand without the need to install and maintain a service, just right under the user context on the first connection from the application. That lets you use almost the same feature set, but with a much simpler management. For deployment, you have to run a separate installer, which don't really requires too much knowledge beyond local admin rights, and then connection and usage is almost the same. This would be a nice trade-off if you're using more function than a simple dumb datastore.</li> </ul> <p>For the client-side DB itself, I would not include in the installer at all. Instead, when the program is running and it first needs to use it, it will try to open it, and if not found, create it from scratch. That can be done though by bundling the DB creation scripts inside the app itself, which will run all of them in sequence to create an empty DB (basically sending a bunch of <code>CREATE TABLE</code>/<code>CREATE VIEW</code>/<code>CREATE PROCEDURE</code>/create whatever). Some ORMs can even automate that step (but I doubt that's a good idea) As this would happen only once, it should not have a big performance impact, and also would make the program resistant if the DB gets deleted somehow. All that must be done on each and every client computer, but I think it may be well possible to create a very dumb next/next/next installer.</p> <p>Now for server-side. It's substantially more difficult to get an easy way to install a server without intervention. Problem basically is that there are a number of configurations that go well beyond your system, but yet can influence it. The DB engine itself is one of such things, as it needs to configure permissions, setup databases, allow external remote connections, enable protocols and configure automatic backups. Also, servers may include firewalls whose ports need to be opened for accepting incoming connections, maybe antivirus messing with network activities and so on.</p> <p>This is the sort of things that I think go beyond what your app can and should ever do, even if that means that the IT people needs to do that manually (which is not much of a burden, as it will be done only once). I don't have much of a nice suggestion here, the suggestion from <code>Sharpeye500</code> is nice in that it allows an unattended SQL Server installation, but only if the right conditions are present, which might not be always the case.</p> <p>What you can automate is the creation of the server-side DB. You can use an "installer" that does the same as I proposed for client-side, that is, send the CREATE DATABASE/CREATE TABLEs statements to build an empty database from scratch. The only required parameters would be the server name/DB name/user/password. The installer can build the connection string from there. The client app may use a similar approach for locating the server DB, and those parameters may be as well included in the client-side installer.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload