Dynamics NAVAX

One advantage with parquet files is that it keeps history. Run the below script and it will give you the history.  %% sql DESCRIBE HISTORY dirpartytable; Below is an example I have in my environment. Use "VERSION AS OF"  Now that you have the history, you can use the VERSION AS OF statement. This will give you the previous values for the record.  %% sql SELECT partynumber, primarycontactphone, primarycontactemail FROM dirpartytable WHERE partynumber = '000001702' ; SELECT partynumber, primarycontactphone, primarycontactemail FROM dirpartytable VERSION AS OF 2 WHERE partynumber = '000001702' ; The below example is when I deleted the primary contact phone number.

This will be a fairly straightforward blog post covering different ways of copying data from a shortcut delta table into a delta table created automatically via a notebook. Select statement with a join %% sql SELECT     party.recid AS PartyId     ,party.name AS Name     ,COALESCE(party.namealias, '' ) AS ShortName     ,COALESCE(postal.countryregionid, '' ) AS Country     ,COALESCE(postal.state, '' ) AS State     ,COALESCE(postal.city, '' ) AS City     ,COALESCE(postal.street, '' ) AS Street     ,COALESCE(postal.zipcode, '' ) AS PostCode     ,COALESCE(phone.locator, '' ) AS PhoneNumber     ,COALESCE(email.locator, '' ) AS Email FROM dirpartytable party LEFT OUTER JOIN logisticspostaladdress postal ON postal. location = party.primaryaddresslocation AND postal.validto > current_date () -- filters only valid(effective) addresses LEFT OUTER JOIN logisticselectronicaddress phone ON phone.recid = party

I’ve recently been exploring various analytical options within Dynamics 365 Finance and Operations, and one that I’ve delved deeply into is Link to Fabric. There is a walkthrough guide available on the Microsoft Fasttrack Github repo . See  Hands-on Lab: Link to Fabric from Dynamics 365 finance and operations apps This guide is an excellent starting point and should be one of the first things you try out. However, it’s important to understand that there are limitations to this approach that may not be suitable for all real-world scenarios. Lets discuss these items and what I have been exploring ... Background I want to join multiple tables to create my denormalised views that I can report on. My goal is to use  Direct Lake  mode in the semantic model. Specifically, I wanted to avoid the need to reimport data into Power BI for reporting.  Key Limitations The first limitation you’ll encounter is: By design, only tables in the semantic model derived from tables in a Lakehouse or Warehouse