Is there a benefit for an internal and external connection command?

[ConstantineK]

One thing we see in dbatools is a lot of work with a lot of tuning is maintain two connection commands to surface different options.

I want to understand more about why this happens and what benefits or downsides I can find, and see if I can isolate the effort inside of one command, or clearly document the bright lines between them.

[ConstantineK]

Checking out Connect-SqlInstance, looks like there's a few items in here that are to manage old version compatibility (with fairly good comments) but I am going to remove them for now.

[ConstantineK]

This code implies to me we need a standardized function that takes in whatever identifier a human would use for an instance, and comes out with a useful SMO Server object (even within the connection functions.)

• a connection object without a credential
• a connection object with a credential
• an ip or hostname
• an ip or hostname, separated by what was traditionally a comma, and then a port
• named pipe \\ServerName\pipe\PipeName

Once we can do that construction, I think the next question to ask is how much the super tuning on connection timing helps, so I am going to write some tests around connection enumeration and see if I can show the cost/benefit.

[ConstantineK]

I think the other open question that this implies is - do we really want to have SqlCredential for every command? I am not too worried about it, but when I think about it more deeply I dont know if its the right choice.

It allows cool passthrough in many cases, but it actually kind of goes into what we are trying to do with the module, and really "How does a sql connection work." (something ephemeral or explicit.)

Do we:

• Encourage opening up a connection with a credential object up front, have the functions validate that you passed the right server type (this seems the most annoying from a "I want to run an individual command against a server") and drop that parameter from all commands (since you would have already setup the credential.)

• Leave a defacto approach in place of allowing an instance and then a credential, even though the only method this really empowers is windows authentication, which may be not the primary goal of the project.

I am just trying to think what sending in the credential gets you separately - and really you might able to build the connection from scratch again after you dispose of the object, but I almost feel like that's an anti-feature?

[SirCaptainMitch]

I think there is value to having a credential param on each command, having used it pretty heavily in all of my commands it makes life a lot easier to not have to build the object manually each time and instead build the credential object with a secret. So I think we need to consider the SQL Login folks out there, because they do exist and I am one of them (for now).

The first option is pretty heavy in that respect.

Ideally, if a function is called and it's just given a name, I would expect the function to attempt to build that object on it's own calling the main Create-SMOObject function. I can see a need for abstraction and keeping the function to its own devices and being expect to pass in a proper object, I just think it adds a lot for the end user to do.