Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel worden veelvoorkomende redenen voor gegevensopnamefouten of beschadigde gegevens geïntroduceerd bij het gebruik van Azure Data Lake Storage of Power Query in Microsoft Dynamics 365 Customer Insights - Gegevens.
Opnamefouten of beschadigde gegevens met Azure Data Lake Storage
Tijdens gegevensopname zijn enkele van de meest voorkomende redenen waarom een record als beschadigd kan worden beschouwd:
- De gegevenstypen en veldwaarden komen niet overeen tussen het bronbestand en het schema.
- Het aantal kolommen in het bronbestand komt niet overeen met het schema.
- Velden bevatten tekens waardoor de kolommen niet overeenkomen met het verwachte schema. Bijvoorbeeld verkeerd opgemaakte aanhalingstekens, ongescapede aanhalingstekens, regeleindetekens of tabtekens.
- Partitiebestanden ontbreken.
-
datetimedateofdatetimeoffsetvelden voldoen niet aan de standaardindeling.
Schema of gegevenstype komt niet overeen
Als de gegevens niet in overeenstemming zijn met het schema, wordt het opnameproces voltooid met fouten.
U kunt dit probleem oplossen door de brongegevens of het schema te corrigeren en de gegevens opnieuw op te nemen.
Partitiebestanden ontbreken
Als het opnameproces is geslaagd zonder beschadigde records, maar u geen gegevens kunt zien, bewerkt u uw model.json of manifest.json bestand om ervoor te zorgen dat partities zijn opgegeven. Vervolgens vernieuwt u de gegevensbron.
Als gegevensopname op hetzelfde moment plaatsvindt als gegevensbronnen worden vernieuwd tijdens een automatische vernieuwing van het schema, zijn de partitiebestanden mogelijk leeg of niet beschikbaar voor het systeemproces. U kunt afstemmen op het upstream-vernieuwingsschema door het schema voor systeemvernieuwing of het vernieuwingsschema voor de gegevensbron te wijzigen. Lijn de timing zo uit dat vernieuwingen niet allemaal tegelijk plaatsvinden.
Datum/tijd-velden hebben de verkeerde indeling
De datetime velden in de tabel hebben geen ISO 8601 of en-US indeling. De standaardindeling datetime in Dynamics 365 Customer Insights - Data is en-US.
datetime Alle velden in een tabel moeten dezelfde indeling hebben. Customer Insights biedt ondersteuning voor andere indelingen die aantekeningen of eigenschappen bevatten op bron- of tabelniveau in het model of manifest.json. Bijvoorbeeld:
Model.json
"annotations": [
{
"name": "ci:CustomTimestampFormat",
"value": "yyyy-MM-dd'T'HH:mm:ss:SSS"
},
{
"name": "ci:CustomDateFormat",
"value": "yyyy-MM-dd"
}
]
In een manifest.json-bestand kan de datetime indeling worden opgegeven op tabelniveau of kenmerkniveau. Gebruik "exhibitsTraits" op tabelniveau in de tabel in *.manifest.cdm.json om de datetime notatie te definiëren. Gebruik op kenmerkniveau "appliedTraits" in het kenmerk in tablename.cdm.json.
Manifest.json op tabelniveau
"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 op kenmerkniveau
{
"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"
}
Opnamefouten of beschadigde gegevens met Power Query
Datum/tijd-waarden worden onjuist geparseerd of er treedt een parseringsfout op
De meest voorkomende gegevenstypemismatch treedt op wanneer een datumveld niet is ingesteld op de juiste datumnotatie. Deze ongelijkheid kan komen door de onjuist opgemaakte brongegevens of een onjuiste lokale instelling.
Symptomen van het onjuiste probleem met lokale instellingen:
Wanneer de brongegevens niet kunnen worden geparseerd door de landinstelling die wordt gebruikt, treedt er een opnamefout op. Als '29/08/2023' bijvoorbeeld wordt geparseerd met 'MM/DD/JJJJ', mislukt de opname omdat deze maand 29 niet kan parseren.
Wanneer de brongegevens worden geparseerd met een onjuiste landinstelling, zijn de datum/tijd-waarden onjuist. De brongegevens zijn bijvoorbeeld opgemaakt als 'MM/DD/JJJJ', terwijl de standaardinstelling die wordt gebruikt om de gegevens tijdens opname te parseren, gebruikmaakt van DD/MM/JJJJ. Als gevolg hiervan wordt '8 december 2023' opgenomen als '12 augustus 2023'.
Schermopname toont dat de datum/tijd-notatie onjuist is na invoer.
Resolutie
Als u een onjuiste indeling wilt herstellen, werkt u de brongegevens bij en verwerkt u deze opnieuw.
Als u een onjuiste landinstelling wilt oplossen, wijzigt u het type van alle datum/tijd-velden om alle datum/tijd-velden aan te passen zodat de juiste landinstelling wordt toegepast met Wijzig type>Met gebruik van landinstelling in de Power Query-transformaties. Bijvoorbeeld:
Zie Document of projectlocale voor meer informatie.