[ Parte 1 | Parte 2 | Parte 3 ]
En las partes 1 y 2 de esta serie, presenté ParamParser:un módulo de PowerShell que ayuda a analizar la información de parámetros:incluidos los valores predeterminados:de procedimientos almacenados y funciones definidas por el usuario, porque SQL Server no lo hará por nosotros.
En las primeras iteraciones del código, simplemente tenía un archivo .ps1 que le permitía pegar uno o más cuerpos de módulos en un $procedure codificado. variable. Faltaban muchas cosas en esas primeras versiones, pero hasta ahora hemos abordado varias cosas:
- Ahora es un módulo adecuado – puede ejecutar
Import-Module .\ParamParser.psm1y luego llamar aGet-ParsedParamsdurante una sesión (además de los otros beneficios que obtiene de un módulo). Esta no fue una conversión trivial:felicitaciones nuevamente a Will White. - Compatibilidad con funciones definidas por el usuario – Expliqué en la parte 2 cómo los nombres de funciones son más difíciles de analizar que los nombres de procedimientos; el código ahora maneja esto correctamente.
- Automatización de ScriptDom.dll – no se nos permite redistribuir este archivo clave, y debido a que puede tener problemas si no lo tiene (o si tiene una versión desactualizada), Will creó
init.ps1, que descarga y extrae automáticamente la última versión (actualmente 150.4573.2) y la coloca en la misma carpeta que los demás archivos. - Fuentes adicionales – aún puede pasar un bloque de secuencia de comandos sin procesar si lo desea, pero ahora también puede usar varias instancias y bases de datos como fuentes, hacer referencia a uno o más archivos directamente o extraer todos los
.sqlarchivos de uno o más directorios. Mostraré algunos ejemplos de sintaxis a continuación. - La salida indica la fuente – dado que puede procesar múltiples archivos o bases de datos en una sola llamada, y puede tener múltiples objetos con el mismo nombre, incluida la fuente ayuda a eliminar la ambigüedad. No puedo hacer mucho si tiene dos instancias de
CREATE PROCEDURE dbo.blat ...en el mismo archivo o secuencia de comandos sin procesar, y la fuente ni siquiera se indica si usa-Scripty pasar en una cadena. - Resultado mejorado – aún puede volcar todo a la consola, pero también puede usar
Out-GridViewpara ver los resultados en un formato de cuadrícula (aquí hay un ejemplo aburrido de AdventureWorks2019), o registrar la información de los parámetros en una base de datos para su consumo en otro lugar.
Siga las instrucciones en el archivo Léame para descargar y configurar. Una vez que haya clonado el repositorio, ejecute .\init.ps1 y luego Import-Module .\ParamParser.psm1 . Pruébelo con un ejemplo simple, como:
Get-ParsedParams -Script "CREATE PROCEDURE dbo.a @b int = 5 out AS PRINT 1;" -GridView
Salida (haga clic para ampliar):
Sin embargo, también hay muchas otras combinaciones de parámetros. El encabezado de ayuda muestra una buena parte de la sintaxis posible (y gracias de nuevo a Will por una gran limpieza aquí):
Get-ParsedParams -?
Resultados:
Get-ParsedParams [-Script]Get-ParsedParams [-File]
Get-ParsedParams [-Directorio]
Get-ParsedParams [-ServerInstance]
Algunos ejemplos más
Para analizar todos los objetos en c:\temp\db.sql :
Get-ParsedParams -File "C:\temp\db.sql" -GridView
Para analizar todos los archivos .sql en c:\temp\scripts\ (recursivo) y h:\sql\ (también recursivo):
Get-ParsedParams -Directory "C:\temp\scripts\", "H:\sql\" -GridView
Para analizar todos los objetos en msdb en la instancia con nombre local SQL2019 utilizando la autenticación de Windows:
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -GridView
Para analizar todos los objetos en msdb , floob y AdventureWorks2019 en la instancia con nombre local SQL2019 y se le solicitarán las credenciales de autenticación de SQL:
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb","floob","AdventureWorks" -AuthenticationMode "SQL" -GridView
Para analizar todos los objetos en msdb en la instancia con nombre local SQL2019 y pase las credenciales de autenticación de SQL:
$password = ConvertTo-SecureString -AsPlainText -Force -String "Str0ngP@ssw0rd" $credential = New-Object -TypeName "PSCredential" -ArgumentList "SQLAuthUsername", $password Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -AuthenticationMode "SQL" -SqlCredential $credential -GridView
Para analizar todos los archivos .sql en c:\temp\scripts\ (recursivo) y coloque los resultados en una tabla en la instancia local con nombre SQL2019 en una base de datos, Utility , donde ya ha creado dbo.ParameterSetTVP , dbo.LogParameters , etc., mediante la autenticación de Windows:
Get-ParsedParams -Directory "C:\temp\scripts" -LogToDatabase -LogToDBServerInstance ".\SQL2019" -LogToDBDatabase "Utility"
Para analizar todos los objetos en msdb en la instancia con nombre local SQL2019 y escribe en la Utility base de datos en la misma instancia, utilizando las mismas credenciales de autenticación de SQL:
$password = ConvertTo-SecureString -AsPlainText -Force -String "Str0ngP@ssw0rd"
$credential = New-Object -TypeName "PSCredential" -ArgumentList "SQLAuthUsername", $password
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -AuthenticationMode "SQL" -SqlCredential $credential -LogToDatabase `
-LogToDBServerInstance ".\SQL2019" -LogToDBDatabase "Utility" -LogToDBAuthenticationMode "SQL" -LogToDBSqlCredential $credential Eso empieza a complicarse, pero espero que lo estés automatizando y no tecleándolo a mano cada vez.
La próxima vez
Como siempre, hay más mejoras que se pueden hacer. No me gustan los nombres de los parámetros que se me ocurrieron, pero creo que hay mejoras más importantes, como el manejo de errores y la extensibilidad que deberían hacerse. ¿Alguna sugerencia? Por favor, házmelo saber o, mejor aún, ¡contribuye!
[ Parte 1 | Parte 2 | Parte 3 ]
