none
Export-Csv Spaltennamen auslesen für leere SQL-Tabellen RRS feed

  • Frage

  • Hallo,

    ich arbeite derzeit viel mit dem SQLPS-Modul und wollte fragen ob es möglich ist, für leere Tabellen die Spaltennamen auszulesen. Mein Ansatz funktioniert derzeit so:

    invoke-sqlcmd -Query $Q  -ServerInstance $s -Database $d | Export-Csv $csv -NoType
    
    if(!(GC $csv)){            
        cd "SQLServer:\SQL\$s\Databases\$d\Views\$t\Columns"
        (GCI | Sort-Object ID | Foreach-Object{$_.Name}) -Join $delimiter | Out-File $csv  
    }

    Was mich an dieser Prüfung allerdings stört ist , dass sie nicht so toll zum Automatisieren ist, da es sich um Tables oder Views handeln kann, bzw. der Servername nicht immer einen Instanznamen aufweißt, was automatisch zu einem \Default führt nach dem Servernamen und somit eine Exception folgt. Des Weiteren möchte ich mir den Parameter $t einsparen, da dieser ja schon im Query enthalten ist.

    Falls dies nicht möglich sein sollte, wär ich über alternative Vorschläge sehr erfreut!

    Ergänzung: Den Instanznamen hab ich mal mittels Regex gelöst.
    • Bearbeitet speedcar343 Mittwoch, 9. Januar 2013 07:58
    Mittwoch, 9. Januar 2013 07:29

Antworten

  • Mittlerweile bin auf folgendes gekommen

    try{
    cd "SQLServer:\SQL\$s\Databases\$d\Views\$t\Columns" -EA "Stop"

    } catch [System.Exception]{ cd "SQLServer:\SQL\$s\Databases\$d\Tables\$t\Columns" }

    ist dies zulässig mittels try\catch oder wäre es besser das ganze mittels if-verzweigungen abzufragen?


    • Als Antwort markiert speedcar343 Donnerstag, 10. Januar 2013 19:11
    Mittwoch, 9. Januar 2013 10:26

Alle Antworten

  • Mittlerweile bin auf folgendes gekommen

    try{
    cd "SQLServer:\SQL\$s\Databases\$d\Views\$t\Columns" -EA "Stop"

    } catch [System.Exception]{ cd "SQLServer:\SQL\$s\Databases\$d\Tables\$t\Columns" }

    ist dies zulässig mittels try\catch oder wäre es besser das ganze mittels if-verzweigungen abzufragen?


    • Als Antwort markiert speedcar343 Donnerstag, 10. Januar 2013 19:11
    Mittwoch, 9. Januar 2013 10:26
  • Ich schließe den Thread mal ab, da ich mit der jetzigen Lösung gut leben kann. Geht mir eigentlich nur mehr um die Frage, ob es legitim ist, Exceptions für solche Zwecke zu missbrauchen, da ein Programm/Script im Normalfall doch keine Exceptions produzieren soll?  Das ist aber hier regelmäßig der Fall...
    Bitte um Korrektur falls ich mich irre.

    gruß speedy

    Donnerstag, 10. Januar 2013 19:10
  • Auf deine SQL Frage konnte ich dir nicht Antworten, da ich das SQL Modul nicht nutze.

    Ja es ist legitim Try{} catches{} so zu benutzen. Genau dafür sind sie gedacht! Wenn ein Fehler auftritt fange ihn auf und reagiere so, dass der User weiterarbeiten kann. Wenn der Fehler so schwer ist das er vom Code selbst nicht behoben werden kann, dann erzeuge eventuell einen neuen Error mit throw und einer sinnvollen Fehlermeldung oder reiche die Original Exception in dem Catch zweig durch.

    Die Exception System.Exception ist eine Universal angabe. Diese Fängt alle Fehler ab. genauso wie ein leeres catch!
    Im Catch sollte man aber am besten die Exception abfangen die am spezifischsten den Fehler beschreibt.

    Siehe:

    Get-Help about_Try_Catch_Finally -FULL # -online # Bei PowerShell 3.0 eventuell zusätzlich den -online Parameter nehmen




    Please click “Mark as Answer” if my post answers your question and click “Vote As Helpful” if my Post helps you.
    Bitte markiere hilfreiche Beiträge von mir als “Als Hilfreich bewerten” und Beiträge die deine Frage ganz oder teilweise beantwortet haben als “Als Antwort markieren”.
    My PowerShell Blog http://www.admin-source.info
    [string](0..21|%{[char][int]([int]("{0:d}" -f 0x28)+('755964655967-86965747271757624-8796158066061').substring(($_*2),2))})-replace' '
    German ? Come to German PowerShell Forum!

    Freitag, 11. Januar 2013 06:13