# Ändringstabeller

Du kan använda verktyg för din måländpunkt för att få information med hjälp av metadata i ändringstabellerna. Dessa data definieras i rubrikkolumnerna som läggs till i ändringstabellschemat. De här rubrikerna beskrivs i tabellen nedan.

För alla mål i replikeringsuppgiften underhålls en ändringstabell med motsvarande namn i databasen med måltabellerna. Mer information finns i [Arbeta med Ändringstabeller](https://help.qlik.com/sv-SE/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Replicating/use_change_table_model.htm). En ändringstabell innehåller de ursprungliga tabellkolumnerna och rubrikkolumnerna. Rubrikkolumnerna innehåller ett prefix så att namnet inte kommer i konflikt med källtabellens kolumnnamn. Standardprefixet är `header__`. Mer information om hur det här prefixet ändras finns i listan Ändringstabeller under Metadata i Uppgiftsinställningar. I följande tabell listas standardrubrikerna för ändringstabellkolumner.

| Kolumnnamn | Typ | Beskrivning |
| --- | --- | --- |
| `[header__]change_seq` | VARCHAR (35) | En monotont ökande ändringssekvens som är gemensam för alla ändringstabeller för en uppgift. Ändringssekvensen har följande format:<br><br>ÅÅÅÅMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx<br><br>Där:<br><br><ul> <li>ÅÅÅÅ anger år (till exempel 2012)</li> <li>MM anger månad (01–12)</li> <li> <p>DD anger datum (01–31)</p> </li> <li>HH anger timme (00–23)</li> <li>mm anger minut (00–59)</li> <li>SS anger sekund (00–59)</li> <li>hh anger hundradelar av en sekund (00–99)</li> <li>xxxxxxxxxxxxxxxxxxx är ett 19-siffrigt ändringsnummer med noll som prefix (globalt per uppgift)</li> </ul><br><br>Tidsdelen avser vanligen tiden för genomförandet av den transaktion som omfattar ändringsposten. Qlik Talend Data Integration innehåller logik som bibehåller monotonin i sekvensnumret så att om tiden för ändpunkten ändras eller justeras kan det leda till flera ändringar som verkar ligga inom samma tidsmarkör men med ökande ändringsnummer.<br><br>xxx...xxx är vanligen det interna ändringsnumret från dataposten bortsett från att för BEFORE-IMAGE-poster är det detsamma som ändringsnumret för den matchande UPDATE-posten (till exempel om ändringsnumret för BEFORE-IMAGE är 1000 och det för UPDATE är 1001, så har båda 1001). Detta möjliggör enkel vänsterriktad yttre sammanfogning mellan tabellen och sig själv, varvid vi söker på vänster sida till tidpunkten, men filtrerar bort `operation=before-image`, och till höger sammanfogar vi på samma `change_seq` med `change_oper` som "B". |
| `[header__]change_oper` | VARCHAR (1) | Åtgärdstyp. Detta kan vara en av följande:<br><br><ul> <li><code>I</code>: Infoga:</li> <li><code>D</code>: Ta bort</li> <li><code>U</code>: Uppdatera</li> <li><code>B</code>: före bild</li> </ul> |
| `[header__] change_mask` | VARBINARY (128) | Ändringsmasken anger vilka datakolumner i ändringstabellen som är associerade med kolumner som har ändrats i källtabellen.<br><br>Bit-positionen i ändringsmasken baseras på kolumnens ordningstal i ändringstabellen. Det innebär att om det finns fem rubrikkolumner tar de upp bitarna 0 till 4 och den första datakolumnen är bit 5 i ändringsmasken.<br><br>Ändringsmasken är en binär kolumn (en byte-matris) som representerar ändringsmasken i little-endian-ordning.<br><br>Byte 0 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0<br><br>Byte 1 bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8<br><br>I det här exemplet anger `bit#N` att ändringstabellkolumnen med ordningstal N avser en kolumn som har ändrats i källtabellen. Om uppdateringsmasken är 11 000 och kolumnens ordningstal är 3 har kolumnen inte ändrats.<br><br>Nedan beskrivs bit-semantiken:<br><br><ul> <li>För INSERT-poster har de associerade bitarna ställts in för alla infogade kolumner.</li> <li>För DELETE-poster har bara primärnyckel- (eller unikt index-) kolumner de tillhörande bitarna inställda. På så sätt kan en tillämpare konstruera en DELETE-sats utan att behöva leta upp primärnyckelfälten från en annan källa.</li> <li>För BEFORE-IMAGE-poster är alla bitar rensade (ändringsmasken kan vara tom).</li> <li>För UPDATE-poster kommer alla kolumner vars värde har ändrats mellan BEFORE-IMAGE och UPDATE att ha den associerade biten inställd.</li> </ul><br><br>Det verkliga antalet bytes som lagras i ändringsmasken kan nulltrimmas. Detta innebär att efterföljande nollor inte behöver lagras. Detta måste beaktas i hanteringslogiken. |
| `[header__] stream_position` | VARCHAR (128) | Strömpositionen för käll-CDC. |
| `[header__] operation` | VARCHAR (12) | Den åtgärd som är associerad med ändringsposten. Den kan vara någon av följande:<br><br><ul> <li>Infoga:</li> <li>Uppdatera</li> <li>Radera</li> <li>BEFOREIMAGE</li> </ul> |
| `[header__] transaction_id` | VARCHAR (32) | ID:t för den transaktion som ändringsposten tillhör.<br><br>Värdet är en hex-sträng för 128-bitars transaktions-ID:t. |
| `[header__] timestamp` | tidsmarkör | Den ursprungliga UTC-tidsmarkören för ändringen (värdet kan vara ungefärligt).<br><br>Anteckning om information Med en PostgreSQL-källa blir tidsmarkören känd först efter att den har överförts. Därför kommer standarddatumet (t.ex. 1970-01-01) att visas tills ändringarna bekräftas i källtabellerna. |
| [rubrik\_\_] `partition_name` | sträng | Namnet på partitionen som skapades på målet när Ändring av datapartitionering är aktiverat. Partitionsnamnet består av partitionens start- och sluttid.<br><br>Exempel:<br><br>20170313T123000\_20170313T170000 |