You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: public/Invoke-DbaQuery.ps1
+83-7Lines changed: 83 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -64,6 +64,8 @@ function Invoke-DbaQuery {
64
64
.PARAMETERNoExec
65
65
Use this switch to prepend SET NOEXEC ON and append SET NOEXEC OFF to each statement, useful for checking query formal errors
66
66
67
+
.PARAMETERAppendConnectionString
68
+
Appends to the current connection string. Note that you cannot pass authentication information using this method. Use -SqlInstance and optionally -SqlCredential to set authentication information.
67
69
68
70
.NOTES
69
71
Tags: Database, Query, Utility
@@ -152,8 +154,22 @@ function Invoke-DbaQuery {
152
154
PS C:\> Invoke-DbaQuery -SqlInstance $server -Query 'SELECT * FROM bar WHERE SSN_col = @SSN' -SqlParameter @inputparamSSN
PS C:\> Invoke-DbaQuery -SqlInstance $server -Query 'SELECT foo FROM bar'
161
+
162
+
Reuses Connect-DbaInstance, leveraging advanced paramenters, to adhere to official guidelines to target FCI or AG listeners.
163
+
See https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/sqlclient-support-for-high-availability-disaster-recovery#connecting-with-multisubnetfailover
Leverages your own parameters, giving you full power, mimicking Connect-DbaInstance's `-MultiSubnetFailover -ConnectTimeout 60`, to adhere to official guidelines to target FCI or AG listeners.
169
+
See https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/sqlclient-support-for-high-availability-disaster-recovery#connecting-with-multisubnetfailover
(-not$ReadOnly) -and# no readonly intent is requested and
395
412
(-not$Database-or$instance.InputObject.ConnectionContext.DatabaseName-eq$Database) # the database is not set or the currently connected
396
413
if ($startedWithAnOpenConnection) {
397
-
Write-Message-Level Debug -Message "Current connection will be reused"
398
-
$server=$instance.InputObject
414
+
Write-Message-Level Debug -Message "Current connection can be reused"
415
+
# We got another nightmare to solve, but fortunately @andreasjordan is "the king"
416
+
# So. Here we are with a passed down "Server" instance. Problem is, we got two VERY different
417
+
# libraries built with VERY different agendas. And we want to get the best of both worlds.
418
+
# This is SUCH a nightmare because Invoke-DbaQuery is THE ONLY function that CAN use a Connection
419
+
# (Microsoft.Data.SqlClient.SqlConnection) which can be used to run PARAMETRIZED queries.
420
+
# So, recap of the recap:
421
+
# 1. Microsoft.Data.SqlClient.SqlConnection:
422
+
# PRO: is the only connection that can use Microsoft.Data.SqlClient.SqlCommand
423
+
# that can use [Microsoft.Data.SqlClient.SqlParameter]s
424
+
# CON: when using integrated auth, as in Integrated Security=True, cannot specify a DIFFERENT user than the current logged in one
425
+
# 2. Microsoft.SqlServer.Management.Smo.Server
426
+
# PRO: can specify a DIFFERENT user than the current logged in one via ConnectAsUser, ConnectAsUserName, ConnectAsUserPassword when Integrated Security=True
427
+
# CON: cannot use Microsoft.Data.SqlClient.SqlCommand nor [Microsoft.Data.SqlClient.SqlParameter]s
428
+
#
429
+
# Till here, everything is clear: we want to reuse connection if we're sure the target is "95%" adherent to the supposed one
430
+
# But, and that's a big but, the magic in Invoke-DbaQuery is making a Microsoft.SqlServer.Management.Smo.Server connection happen, let it "bleed" through here
431
+
# land in Invoke-DbaAsync untouched, where it gets magically converted to a Microsoft.Data.SqlClient.SqlConnection, and we get the best of both worlds.
432
+
# Thing is, the "magic" is rather ... not so magic. What it happens is that when the connection from Microsoft.SqlServer.Management.Smo.Server is "Open",
433
+
# everything works fine, while if it's "Closed", Microsoft.Data.SqlClient.SqlConnection rehydrates a connection using the ConnectionString of Microsoft.SqlServer.Management.Smo.Server.
434
+
# Microsoft.SqlServer.Management.Smo.Server is cheating though, because there's no connectionstring parameter that holds "log on as a different user", so, what happens is that
435
+
# when Microsoft.Data.SqlClient.SqlConnection picks it up, rehydrates the connection that holds Integrated Security=True, and the information on "log on as a different user" is lost in
436
+
# translation.
437
+
# As anticipated, this happens ONLY when the connection is "Closed", because when it's "Open", no rehydration is needed, and everything works out of the box.
438
+
# Now, another fancy thing: we want to use connection pooling by default, because pooling connection is more performant.
439
+
# But, and that's the big but, when connection is pooled, it gets put in the "Closed" state which translates to "back to the pool, ready to be reused", as soon as no commands are actively used.
440
+
# In dbatools world, that means pretty much that when we are here, it's always "Closed" UNLESS -NonPooledConnection is $true on Connect-DbaInstance, and that's why when we don't land here
441
+
# we create a new instance with NonPooledConnection = $true ( see #8491 for details, also #7725 is still relevant)
442
+
# If -NonPooled is passed, we instruct Microsoft.SqlServer.Management.Smo.Server we DON'T want pooling, so the connection stays "Open" (there's no pool to put it back),
443
+
# and when it's "Open" we can leverage the fact that we already established a connection, verified the certificate, did the login handshake, etc AND when casting
444
+
# to Microsoft.Data.SqlClient.SqlConnection it enables us to leverage [Microsoft.Data.SqlClient.SqlParameter]s !
445
+
#
446
+
# Again, here we are, but we cannot use the connection when an information is lost, which is that we are:
447
+
# - Integrated Security=True
448
+
# - using ConnectAsUser, ConnectAsUserName, ConnectAsUserPassword to "log on as a different user"
449
+
450
+
if ($instance.InputObject.ConnectionContext.ConnectAsUserName-ne'') {
451
+
Write-Message-Level Debug -Message "Current connection cannot be reused because logging in as a different user"
452
+
# We rebuild correct credentials from SMO informations
0 commit comments