Lesestoff / Linksammlung

Momentan habe ich echt viel zu tun, trotzdem gibt es immer mehr als genug neuen Lesestoff. Nachfolgend ein kleiner Auszug, muss zugeben, habe selber noch nicht alles gelesen. Aber dafür ist dieser Blogbeitrag ja da, sprich ich kann später nachschlagen…

Power Platform:

Codeunit API’s in Business Central

Power Apps Community Plan without Office 365

Using Power BI service without an Office 365 account

Currency Conversion in Power BI Reports

THE HIDDEN GEMS OF THE FUNCTION WEB.CONTENTS()

Moving X-Axis in Power BI

Analyzing PASS SQL Saturday data using Power BI

Paginated Reports Bonus Tutorial – Use the XMLA endpoint to create a live connected Excel table

https://www.fourmoo.com/2020/02/12/how-you-can-store-all-your-power-bi-audit-logs-easily-and-indefinitely-in-azure/

Read API Data with Power BI using Power Query

 

NAV Business Central:

Codeunit API’s in Business Central

Business Central Blog

Import Tenant Data

How to use the Excel Buffer in Business Central cloud

Another great BC Blog

And another great Blog….

Dynamics 365 Business Central Workflows Auto Posting Transactions

 

SQL:

SQL CROSS JOIN examples

Split Delimited String with Split Delimited with PARSENAME function

 

Azure:

Cloud ETL With Azure Data Factory & CDS

Custom Logging and Auditing of ADF Data Flows

Syncing on-premise databases to Microsoft Azure Cloud using Azure Data Factory

Azure Functions Live – Feb 2020

 

Office:

Typescript – The Excel VBA Killer?

Create a Star Schema Data Model in SQL Server using the Microsoft Toolset

Es wurde ja schon oft genug gesagt, auch in Power BI ist das A und O eines erfolgreichen Projektes ein gut durchdachtes Datenmodell. Hier mal ein Beitrag, der aus Sicht vom SQL Server zeigt, wie so ein Designprozess aussehen kann.

Create a Star Schema Data Model in SQL Server using the Microsoft Toolset

Links, Links, Links

Man möchte eigentlich meinen, in der Sommerzeit hat man mehr Zeit zum Lesen interessanter Beiträge. Bei mir ist es genau umgekehrt, da ich mich in dieser Jahreszeit gerne und viel an der frischen Luft bewege. Trotzdem habe ich mal wieder einige interessante Beiträge zusammen getragen. Ein bunter Reigen, der zeigt, was mich so alles interessiert…

Read and Write Excel files in real-time with R in SQL Server 2017

Power BI Regression Report

API:

https://www.programmableweb.com/news/bing-maps-time-zone-api-now-generally-available/brief/2018/08/15

https://www.programmableweb.com/news/how-to-access-any-restful-api-using-r-language/how-to/2017/07/21

https://www.programmableweb.com/api-university/api-developer-training

 

PowerApps progress bar

Using Azure Functions in PowerApps

SQL table to HTML

 

xRMVirtual User Group

Need Icons?

Microsoft Flow blog

Solving Real World Scenarios with Microsoft Flow – Challenge No. 2

This is the second challenge:

+ Periodically get currency exchange rates from a web service

+ Insert the rows in a staging table (SQL Database On-premise)

+ Parse inserted Json Data with a stored procedure and insert results in our final Currency Exchange Rates Table.

The resulting Flow would look like this:

captur1

Let’s get things started:

HTTP: I’m using fixer.io to get my data. No Problem so far.

Insert Row: I have installed and configured the On-premises data gateway and it’s working.

Execute stored procedure: Here comes trouble:

capture

Sadly up to now stored procedures are no supported when using a gateway. But hopefully we get this feature soon as stated here.

I then figured out the following workaround. Create an AfterInsert Trigger on the staging table to transfer my data to the final table. But I had now luck:

capture2

After some investigation, I found this thread. Currently you can’t use the Insert Row action on a table with an existing trigger.

So, this is really bad. At present neither stored procedures nor triggers are supported when dealing with Microsoft SQL Databases via the On-premises data gateway. Challenge lost at least for the moment.

 

SQL und Abfrage auf Datumsfelder

Ein durchaus interessanter Beitrag zum Thema SSIS und Abarbeitung abhängig von Wochentag

http://billfellows.blogspot.co.at/2016/02/ssis-conditional-processing-by-day.html

führt int weiterer Folge zu einem Beitrag über SQL und Abfragen auf Datumswerte und was man da alles so falsch machen kann (erwischt, wie oft habe ich schon so ähnliche Abfragen gemacht, nur weil es schnell gehen musste):

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/16/bad-habits-to-kick-mishandling-date-range-queries.aspx

 

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