0

I am trying to figure out a solution where a customer will not have access to the source code to a Windows desktop application (and so won't be able to recompile the application) but they will have control over their SQL Server instance, which they may wish to relocate to a different server at some time in the future.

We can specify Integrated Security in the connection string and either the server's IP address or its network name.

But where could that connection string itself be kept so that the customer could edit it if they need to relocate the SQL Server instance, and the application will always be able to find it and read it?

Assume that the software developers have all been beamed up into a UFO by extraterrestrials. They are not available to recompile the application either.

Tim
  • 8,669
  • 31
  • 105
  • 183
  • 2
    Why not make it config driven? You could do app.configs or machine configs. Alternatively, look up DSN entries; I personally dislike them, but they would work for this I think. – UnhandledExcepSean Jun 05 '19 at 13:29
  • Is `localhost` a valid `ServerName` for the `SQLDataSources` method in the ODBC32.dll? – Tim Jun 05 '19 at 13:34
  • Editing `AppName.exe.config` would work, though it would be better to keep the customer out of that file. – Tim Jun 05 '19 at 13:42
  • I'm getting flashbacks to ODBC Data Source Names. Let's not revisit those times. – Dai Jun 05 '19 at 13:48
  • Configs are the best thing for customers to change in my opinion. Easy to back up, easy to restore, easy to version control, easy to review, and easy to change. If you don't trust them to update the config directly, you can always make a maintenance interface for them to use and encrypt the output. – UnhandledExcepSean Jun 05 '19 at 13:51

0 Answers0