Share via


Häufige Gründe für Erfassungsfehler oder beschädigte Daten

Anmerkung

Dynamics 365 Marketing und Dynamics 365 Customer Insights sind jetzt Customer Insights - Journeys und Customer Insights - Data. Weitere Informationen finden Sie in den Dynamics 365 Customer Insights – FAQs.

Es gibt mehrere häufige Gründe, die zu Datenerfassungsfehlern führen.

Häufige Gründe für Erfassungsfehler oder beschädigte Daten mit Azure Data Lake Storage

Einige der häufigsten Gründe, warum ein Datensatz während der Datenerfassung als beschädigt angesehen werden könnte, sind:

  • Die Datentypen und Feldwerte zwischen der Quelldatei und dem Schema stimmen nicht überein.
  • Die Anzahl der Spalten in der Quelldatei stimmt nicht mit dem Schema überein.
  • Felder enthalten Zeichen, die dazu führen, dass die Spalten vom erwarteten Schema abweichen. Beispiel: falsch formatierte Anführungszeichen, nicht durch Escape-Zeichen formatierte Anführungszeichen, Zeilenumbruchzeichen oder Zeichen im Registerkartenformat.
  • Partitionsdateien fehlen.
  • Wenn datetime/date/datetimeoffset-Spalten vorhanden sind, muss deren Format im Schema angegeben werden, wenn es nicht dem Standardformat entspricht.

Schema- oder Datentypkonflikt

Wenn die Daten nicht dem Schema entsprechen, wird der Erfassungsprozess mit Fehlern abgeschlossen. Korrigieren Sie entweder die Quelldaten oder das Schema und erfassen Sie die Daten erneut.

Partitionsdateien fehlen

  • Wenn die Erfassung ohne beschädigte Datensätze erfolgreich war, Sie aber keine Daten sehen können, bearbeiten Sie Ihre model.json- oder manifest.json-Datei, um sicherzustellen, dass Partitionen angegeben sind. Aktualisieren Sie dann die Datenquelle.

  • Wenn die Datenerfassung gleichzeitig mit der Aktualisierung von Datenquellen während einer automatischen Zeitplanaktualisierung erfolgt, sind die Partitionsdateien möglicherweise leer oder für den Systemprozess nicht verfügbar. Zur Ausrichtung an den Upstream-Aktualisierungszeitplan ändern Sie den Systemaktualisierungszeitplan. Passen Sie den Zeitpunkt so an, dass nicht alle Aktualisierungen gleichzeitig erfolgen.

DateTime-Felder im falschen Format

Die DateTime-Felder in der Tabelle sind nicht im ISO 8601- oder im en-US-Format. Das Standardformat für Datum und Uhrzeit in Dynamics 365 Customer Insights - Data ist das Format „en-US“. Alle DateTime-Felder in einer Tabelle sollten dasselbe Format haben. Customer Insights unterstützt andere Formate, sofern Anmerkungen oder Merkmale auf Quell- oder Tabellenebene in der model- oder manifest.json-Datei vorgenommen werden. Zum Beispiel:

Model.json

   "annotations": [
     {
       "name": "ci:CustomTimestampFormat",
       "value": "yyyy-MM-dd'T'HH:mm:ss:SSS"
     },
     {
       "name": "ci:CustomDateFormat",
       "value": "yyyy-MM-dd"
     }
   ]   

In einer manifest.json-Datei kann das DateTime-Format auf Tabellenebene oder auf Attributebene angegeben werden. Verwenden Sie auf der Tabellenebene „exhibitsTraits“ in der Tabelle in der *.manifest.cdm.json, um das DateTime-Format zu definieren. Verwenden Sie auf Attributebene „appliedTraits“ im Attribut in der Datei tablename.cdm.json.

Manifest.json auf Tabellenebene

"exhibitsTraits": [
    {
        "traitReference": "is.formatted.dateTime",
        "arguments": [
            {
                "name": "format",
                "value": "yyyy-MM-dd'T'HH:mm:ss"
            }
        ]
    },
    {
        "traitReference": "is.formatted.date",
        "arguments": [
            {
                "name": "format",
                "value": "yyyy-MM-dd"
            }
        ]
    }
]

table.json auf Attributebene

   {
      "name": "PurchasedOn",
      "appliedTraits": [
        {
          "traitReference": "is.formatted.date",
          "arguments" : [
            {
              "name": "format",
              "value": "yyyy-MM-dd"
            }
          ]
        },
        {
          "traitReference": "is.formatted.dateTime",
          "arguments" : [
            {
              "name": "format",
              "value": "yyyy-MM-ddTHH:mm:ss"
            }
          ]
        }
      ],
      "attributeContext": "POSPurchases/attributeContext/POSPurchases/PurchasedOn",
      "dataFormat": "DateTime"
    }

Häufige Gründe für Erfassungsfehler oder beschädigte Daten mit Power Query

Beim Parsen der Datums- und Uhrzeitwerte ist ein Fehler aufgetreten oder sie wurden falsch analysiert

Der häufigste Datentypkonflikt tritt auf, wenn ein Datumsfeld nicht auf das richtige Datumsformat eingestellt ist. Diese Nichtübereinstimmung kann folgende Ursachen haben: Die Quelldaten sind nicht richtig formatiert ODER das Gebietsschema ist falsch. Um ein falsches Format zu korrigieren, aktualisieren Sie die Daten an der Quelle und erfassen sie erneut. Um ein falsches Gebietsschema zu korrigieren, passen Sie das Gebietsschema in den Power Query-Transformationen an. Zum Beispiel:

Die Quelldaten sind als „MM/TT/JJJJ“ formatiert, während das Standardgebietsschema, das zum Parsen der Daten während der Erfassung verwendet wird, „TT/MM/JJJJ“ verwendet, wodurch der 8. Dezember 2023 als „12. August 2023“ erfasst wird.

Datentyp mit Gebietsschema in PQO ändern

Um dieses Problem zu beheben, ändern Sie den Typ aller Datums-/Uhrzeitfelder, um das richtige Gebietsschema zu verwenden, indem Sie Typ ändern>Gebietsschema verwenden verwenden.

Standardanalyse des Datums-/Uhrzeitwerts

Zu den Symptomen eines falschen Gebietsschemas gehören:

  • Wenn die Quelldaten vom verwendeten Gebietsschema nicht analysiert werden können, was zu einem Erfassungsfehler führt. Beispiel: Der 29.08.2023 wird mit MM/TT/JJJJ geparst, dies schlägt fehl, da Monat 29 nicht geparst werden kann.
  • Wenn die Quelldaten mit einem falschen Gebietsschema erfolgreich analysiert werden, die Datums- und Uhrzeitwerte jedoch falsch werden. Beispiel: Der 8. Dezember 2023 wird als 12. August 2023 erfasst.

Weitere Informationen: Dokument- oder Projektgebietsschema.

Trinkgeld

Informationen zur Fehlerbehebung finden Sie unter Microsoft Dynamics 365 Customer Insights Fehlerbehebung.