Task Scheduler – Excel – Läuft nicht

Habe schon seit Langem einen Geplanten Task am Laufen, welcher Daten mittels VBA aus dem SQL-Server zieht und damit eine Excelvorlage füllt. Aus heiterem Himmel lief dieser nicht mehr. Nach längerer Suche bin ich dann auf diese Beiträge gestossen. Die Lösung war doch tatsächlich, die darin angegebenen Ordner anzulegen, die Excel scheint’s braucht. Sachen gibt’s ….

http://stackoverflow.com/questions/37010776/vba-fails-when-task-scheduler-is-set-to-run-whether-user-logged-on-or-not

https://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64?forum=innovateonoffice

SSIS, SSRS, SQL zwei Linktipps

Mal wieder eine Seite mit sehr interessanten Lösungsansätzen zu täglichen Problemen beim Einsatz von SSIS und SSRS:

http://www.bechtle-blog.com/home/author/363

Und dann noch dieser Link, welchen ich auf SqlServerCentral gesehen habe:

https://blogs.technet.microsoft.com/uktechnet/2016/04/25/catch-up-sql-server-for-the-bi-professional/

 

 

MOC 20463 – Notizen – Teil 1

Teil 1 meiner Aufzeichnungen zum Kurs, werde versuchen dem Ganzen mit Links und weiteren Kommentaren nach und nach noch etwas Leben einzuhauchen:

  • Extending SSIS durch Komponenten, vor allem im Bereich ftp, Komprimierung sind externe Komponenten im Einsatz
  • Deploying von SSIS-Pakten, aber SQL 2012 unbedingt SSIS-Katalog verwenden (Versionierung, umfangreiches Logging und aussagekräftiges Reporting out of the box)
  • Performance für Data Warehouse Server, wichtig CPU und genügend RAM
  • Datensicherungsmodell Simple in den meisten Fällen ausreichend
  • Security, mittels Views, wenn Lösung nicht allzu komplex ist, ansonsten über SSAS, ab SQL 2016 kann Security auch mit WHERE Clauses in den Views gearbeitet werden, allerdings fehlen noch Erfahrungen betreffend Performance
  • Staging Tables sind zwar weit verbreitet, sollten aber falls möglich vermieden werden (overhead)
  • Wie bereits erwähnt Daten für Auswertungstools immer per Views bereit stellen (Änderungen im Betrieb leicht möglich)
  • Datentypen in views explizit definieren
  • Visio verwenden, um Datenbankdiagramme vernünftig darzustellen
  • SSMS hat ja das allbekannte Problem mit dem Refresh bei Änderungen, auch zusätzlich im Query Editor erforderlich (Menü – IntelliSense – Refresh Local Cache)
  • SSIS-Entwicklung mit Office-Komponenten: möglichst nur an Entwicklermaschine mit 32Bit-Treiber arbeiten, danach Deployment auf SSIS-Server vornehmen, da kann dann mit 64bit-Treibern gefahren werden
  • SSIS-Pakete möglichst nicht verschachteln (ein Paket ruft ein anders auf usw.), ist zwar ein Overhead aber die Wartung ist um Vieles einfacher
  • Package Templates bringen nur auf den ersten Blick Vorteile, besser und einfacher ist es, Basispakete auf Server ablegen und bei Bedarf in neues Paket importieren
  • Variablen möglichst immer alle im Global Scope anlegen, so gibt es nur eine zentrale Anlaufstelle und das versehentliche Anlegen von gleichnamigen Variablen in unterschiedlichen Hierarchien wird so vermieden
  • Expression Builder ist eher schwerfällig und umständlich, besser Scriptask (mit kompletter .net-Unterstützung) verwenden
  • mit der Property Transakation True nur in Ausnahmefällen arbeiten

 

Ugly T-SQL Code

Dabei ertappe ich mich selber immer wieder, wie schnell ist doch ein hässlicher Codeblock, der vielleicht nur ein Prototyp sein sollte, auf einmal live in Verwendung. Darum könnten Tools, wie in diesem Beitrag beschrieben, doch leicht Abhilfe schaffen, muss ich mir anschauen:

http://www.sqlservercentral.com/blogs/cjsommercom/2015/09/29/do-you-write-ugly-t-sql/