Quick question-and-answer session about SQL instance support

  • Article

I got an email from a co-worker asking a few questions about Orcas support for SQL named instances.

Here's his questions and my answers:

  • What is the syntax that you are supporting in TFSADMINUTIL renamedt?
    • same as connection strings - hostname and hostname\instance and hostname,port
  • SQL Browser is not going to necessary for sure right?
    • correct, you can use hostname,port
  • We have had issues a couple of times with being able to connect (with a non-default port-default instance) but then getting a redx on workitems.  Are we still using the tfsurl property in the web.config (I hate it!) I think it had something to do with our problem
    • the web interface isn't changing, only the interface between the AT and DT
  • Do Alias port changes work?
    • not sure what you mean, but if you're using sql client aliases, those should work fine AFAIK.  I don't think we've tested that, though.
  • I seem to see some conflicting messages as far as Olap.  Will AS on a different server be Rosario?
    • AS on a different server was supported with Whidbey SP1 - it's supported at install time as well in Orcas, although you have to edit the msiproperty.ini to do so (setting VSTF_AS_INSTANCE to othermachine\instance or othermachine or othermachine:port)
  • We seemed to build connection strings within some classes (I think).  Are those going to be changed to read from the web.config or database table, or … 
    • if you find those, file bugs about them or at least send an email :)  ideally we read the TfsIntegration location from the web.config and all the others from tbl_database in TfsIntegration
  • For setup,repair,reinstall are we reading from msiproperty.ini?  Using the VSTF_DB_SERVER property?  If so, what syntax’s are allowed here?
    • msiproperty.ini is read from, but then we invoke a tool called GetCurrentTfsProperties that tries to read everything from the existing server/database, so for instance VSTF_DB_SERVER should be set by whatever's in the web.config regardless of what's in the msiproperty.ini.  We already know that there's tons of reasons the msiproperty.ini can get out of date (since none of our tools update it), so we try not to rely on it.
  • Are we supporting tcp:  syntax?
    • I'm not familiar with tcp: syntax, but I've tested with hostname,port (where the port is obviously tcp) and it worked fine.  I would doubt that tcp: would work, since : is special in the connection string (which AFAIK is the reason that database port specification is hostname,port instead of hostname:port like it is for analysis)