hjem › Multimedia › Det ble gjort et forsøk på å sette inn en ikke-unik verdi i en unik indeks. Feil: Forsøk på å sette inn en ikke-unik verdi i en unik indeks: microsoft sql-server. når du bytter fra regnskapsfører til bedrift og ikke bare Fjern ikke-unike indekser i 1c 8-fil

Det ble gjort et forsøk på å sette inn en ikke-unik verdi i en unik indeks. Feil: Forsøk på å sette inn en ikke-unik verdi i en unik indeks: microsoft sql-server. når du bytter fra regnskapsfører til bedrift og ikke bare Fjern ikke-unike indekser i 1c 8-fil

Du har mottatt en melding som inneholder linjene:
Microsoft OLE DB-leverandør for SQL Server: CREATE UNIQUE INDEX avsluttet fordi en duplikatnøkkel ble funnet for indeks-ID
eller
Kan ikke legge inn duplikatnøkkelrad i objektet
eller
Det ble gjort et forsøk på å sette inn en ikke-unik verdi i en unik indeks.

Løsninger:

1. I SQL Server managment studio ødelegger vi fysisk den defekte indeksen (i mitt tilfelle var det en indeks på totaltabellen for regnskapsregisteret). I 1C vil vi distribuere de feilaktige dokumentene. I test- og korreksjonsmodus, merk av i boksene for tabellreindeksering + nyberegning av totaler. 1C gjenskaper indeksen uten feil. Vi utfører tidligere mislykkede dokumenter.

2. 1) Bruke Management Studio 2005 genererte et opprettelsesskript for å lage en indeks, som var buggy, og lagret den i en fil.
2) manuelt drept jamb-indeksen fra tabellen _AccumRgTn19455
3) Lanserte en forespørsel som
SQL-kode S_elect count(*), indeksfelter
FRA AccumRgTn19455
GRUPPER ETTER indeksfelt
HAR telling(*)>1
Etter at indeksen ble drept, hadde jeg 15 dupliserte poster vist, men før trinn 2 returnerte ikke spørringen noe.
4) Jeg gikk gjennom alle oppføringene og ryddet opp i duplikater manuelt. Faktisk brukte jeg også "Rapportstruktur"-behandlingen for å forstå hva jeg hadde å gjøre med. Det viste seg at tabellen _AccumRgTn19455 lagrer akkumuleringsregisteret "Produktutgang (skatteregnskap)". Jeg pirket også med sql-spørringer, identifiserte 15 ikke-unike dokumenter, og etter at alle handlingene var fullført, sjekket jeg i 1C at disse dokumentene ble behandlet normalt, uten feil. Selvfølgelig bør du ikke bare rengjøre bord tilfeldig: det er viktig å forstå hva som blir rengjort og hvordan det kan slå ut.
5) Lanserte en forespørsel om å opprette en indeks, som ble lagret i en fil.
6) Byttet databasen til enkeltbrukermodus og startet dbcc checkdb - denne gangen ble det ikke generert noen feil.
7) Byttet basen tilbake til enkeltbrukermodus.
Det er det... problemet er overvunnet. Vel, tilbake i 1C lanserte jeg "Testing og korrigering", alt gikk bra der også, jeg sluttet å klage på den ikke-unike indeksen.

3. Hvis ikke-unikken ligger i datoer med nullverdier, så løses problemet ved å lage en database med en offset-parameter lik 2000.

1. Hvis problemet laster databasen, gjør du følgende:
1.1. Hvis du laster (ved hjelp av en dt-fil) inn i en MS SQL Server-database, spesifiser datoforskyvningen - 2000 før du oppretter databasen.
Hvis databasen allerede er opprettet med offset 0, må du opprette en ny med 2000.

1.2. Hvis det er mulig å jobbe med databasen i filversjonen, så utfør Testing og Korreksjon, samt Konfigurasjon - Sjekke konfigurasjonen - Sjekke den logiske integriteten til konfigurasjonen + Søke etter feil lenker.

1.3. Hvis det ikke er noen filversjon, prøv å laste fra DT til en klient-tjenerversjon med DB2 (som er mindre krevende for unikhet), og utfør deretter Test og korrigering, samt Konfigurasjon - Bekreft konfigurasjon - Sjekk den logiske integriteten til konfigurasjonen + Søk etter ugyldige referanser.

1.4. For å lokalisere problemet kan du bestemme dataene til objektet hvis lasting mislyktes. For å gjøre dette må du aktivere sporing i Profiler-verktøyet under oppstart eller aktivere opptak i DBMSSQL- og EXCP-prosesshendelsesloggen.

2. Hvis problemet med ikke-unikhet oppstår mens brukere jobber:

2.1. Finn den problematiske forespørselen ved å bruke metoden i avsnitt 1.4.

2.1.2. Noen ganger oppstår det en feil under utføring av spørringer, for eksempel:

Denne feilen oppstår på grunn av det faktum at i akkumuleringsregistermodulen " Arbeidstid ansatte i organisasjoner" i prosedyren "Registrer omberegninger", inneholder ikke forespørselen tjenesteordet "ANNERLEDES".
Kode 1C v 8.x Dvs. bør være:
Forespørsel = Ny forespørsel(
"VELG DIVERSE
| Basic.Individual,
. . . . .
I de siste utgivelsene av ZUP og UPP oppstår ikke feilen, fordi det står "ANNERLEDES".

2.2. Etter å ha funnet den problematiske indeksen fra forrige avsnitt, må du finne en ikke-unik post.
2.2.1. "Fish"-skript for å identifisere ikke-unike poster ved hjelp av SQL:
SQL-kode S_velg COUNT(*)-teller,<перечисление всех полей соответствующего индекса>fra<имя таблицы>
GRUPPE AV<перечисление всех полей соответствующего индекса>
Å HA Teller > 1

2.2.2 Eksempel. Indeksen i feilen heter "_Document140_VT1385_IntKeyIndNG".
Liste over tabellfelt:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld13_3_Ref1393_Ref1393_Fld1393_Ref1393 f, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_Fld22260_Fld22260_1_FldRef,2_FldRef,2_FldRef, 6_FldRef f, _Fld22261_RRRef
Før du utfører prosedyren nedenfor, gjør du sikkerhetskopi Database.
Kjør i MS SQL Server Query Analyzer:
SQL-kode S_elect count(*), _Document140_IDRRef, _KeyField
from_Document140_VT1385
grupper etter _Document140_IDRRef, _KeyField
har telling(*) > 1
Bruk den til å finne ut verdiene til kolonnene _Document140_IDRRef, _KeyField, duplikatposter (id, nøkkel).

Ved å bruke forespørselen:
SQL-kode S_elect *
from_Document140_VT1385
eller _Document140_IDRRef = id2 og _KeyField = nøkkel2 eller ...
se på verdiene til de andre kolonnene i de dupliserte oppføringene.
Hvis begge oppføringene har meningsfulle verdier og verdiene er forskjellige, endrer du _KeyField-verdien til å være unik. For å gjøre dette, bestem den maksimale okkuperte verdien for _KeyField (keymax):
SQL-kode S_elect max(_KeyField)
from_Document140_VT1385
hvor _Dokument140_IDRRef = id1
Erstatt _KeyField-verdien i en av de dupliserte oppføringene med den riktige:
SQL-kodeoppdatering _Document140_VT1385
sett _KeyField = keymax + 1
Her er _LineNo1386 = en tilleggsbetingelse som lar deg velge en av to gjentatte poster.

Hvis en (eller begge) av de dupliserte oppføringene har en åpenbart feil betydning, bør den fjernes:
SQL-kodesletting fra _Document140_VT1385
der _Document140_IDRRef = id1 og _LineNo1386 = lineno1
Hvis dupliserte oppføringer har samme verdier i alle kolonner, må du forlate en av dem:
SQL-kode S_elect distinkt *
inn i #tmp1
from_Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

Slett fra _Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

I_sert inn i _Document140_VT1385
S_velg #tmp1

D_rop-tabell #tmp1

Den beskrevne prosedyren må utføres for hvert par dupliserte poster.

2.2.3. Andre eksempel:
SQL Code S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRA _Referanse8_
GRUPPE ETTER _IDRRef, _Beskrivelse
HAR (COUNT(*) > 1)

2.3.4 Et eksempel på å bestemme ikke-unike poster ved å bruke en 1C:Enterprise-spørring:
Kode 1C v 8.x SELECT Directory.Link
FRA Directory.Directory AS Directory
GRUPPER ETTER Directory.Link
HAR ANTALL(*) > 1

Denne artikkelen vil beskrive hva du skal gjøre hvis du, når du arbeider med 1C:Enterprise 8.1, møter en melding som inneholder linjene:

Kan ikke sette inn duplikatnøkkelrad i objektet

Det ble gjort et forsøk på å sette inn en ikke-unik verdi i en unik indeks.

Hva er en indeks?

Indekser er en struktur som gir rask tilgang til rader i en tabell basert på verdiene til en eller flere av kolonnene.
En indeks inneholder nøkler, bygget fra én eller flere kolonner i en tabell eller visning, og pekere som kartlegger hvor de angitte dataene er lagret.
Indekser reduserer mengden data som må leses for å returnere et resultatsett.

Selv om en indeks er knyttet til en spesifikk kolonne (eller kolonner) i en tabell, er den fortsatt et eget databaseobjekt.

Indekser av tabeller i 1C:Enterprise-databasen opprettes implisitt når du oppretter konfigurasjonsobjekter, så vel som under visse innstillinger av konfigurasjonsobjekter.

Den fysiske essensen av indekser i MS SQL Server 2005.

Fysisk er dataene lagret på 8Kb sider. Umiddelbart etter opprettelsen, mens tabellen ikke har indekser, ser tabellen ut som en haug med data. Postene har ingen spesifikk lagringsrekkefølge.
Når du ønsker å få tilgang til data, vil SQL Server produsere tabellskanning(tabellskanning). SQL Server skanner hele tabellen for å finne postene den leter etter.
Herfra blir de grunnleggende funksjonene til indekser tydelige:
— øke hastigheten på datatilgang,
— støtte for dataunikhet.

Til tross for fordelene har indekser også en rekke ulemper. Den første er indekser ta opp ekstra diskplass og i tilfeldig tilgangsminne. Hver gang du oppretter en indeks lagrer du nøklene i synkende eller stigende rekkefølge, som kan ha en flernivåstruktur. Og jo større/lengre nøkkel, jo større indeksstørrelse. Den andre ulempen er driften bremser opp sette inn, oppdatere og slette poster.
I MS SQL Server 2005-miljøet er flere typer indekser implementert:

ikke-klyngede indekser;
grupperte (eller grupperte) indekser;
unike indekser;
indekser med inkluderte kolonner
indekserte visninger
full tekst

Unik indeks

Det unike til verdiene i den indekserte kolonnen er garantert av unike indekser. Hvis de er tilstede, vil ikke serveren tillate deg å sette inn en ny verdi eller endre en eksisterende verdi på en slik måte at som et resultat av denne operasjonen vises to identiske verdier i kolonnen.
En unik indeks er et slags tillegg og kan implementeres for både grupperte og ikke-klyngede indekser. Én tabell kan ha én unik klynget indeks og mange unike ikke-klyngede indekser.
Unike indekser bør bare defineres når det virkelig er nødvendig. For å sikre dataintegritet på en kolonne kan du definere en UNIQUE eller PRIMÆR NØKKEL integritetsbegrensning i stedet for å ty til unike indekser. Å bruke dem utelukkende for å sikre dataintegritet er sløsing med databaseplass. I tillegg brukes CPU-tid også på å vedlikeholde dem.

1C:Enterprise 8.1, fra og med versjon 8.1, bruker aktivt klyngede unike indekser. Dette betyr at når du konverterer fra 8.0 eller migrerer fra 8.1.7, kan du få en ikke-unik indeksfeil.

Hvis ikke-unikheten ligger i datoer med nullverdier, løses problemet ved å lage en database med en offsetparameter lik 2000.

Hva å gjøre?

1. Hvis problemet laster databasen, gjør du følgende:

1.1. Hvis du laster (ved hjelp av en dt-fil) inn i en MS SQL Server-database, spesifiser datoforskyvningen - 2000 før du oppretter databasen.

Hvis databasen allerede er opprettet med offset 0, må du opprette en ny med 2000.

1.5. Hvis noden (utvekslingsplanene) er tilgjengelig, utfør utvekslingen. Du kan også fylle ut avsnitt 2.3.5 før du bytter

2. Hvis problemet med ikke-unikhet oppstår mens brukere jobber:

2.1. Finn den problematiske forespørselen ved å bruke metoden i avsnitt 1.4.

2.1.2. Noen ganger oppstår det en feil under utføring av spørringer, for eksempel:

De. bør være:

Request = New Request(
"VELG DIVERSE
| Basic.Individual,

I de siste utgivelsene av ZUP og UPP oppstår ikke feilen, fordi det står "ANNERLEDES".

2.2. Etter å ha funnet den problematiske indeksen fra forrige avsnitt, må du finne en ikke-unik post.

2.2.1. "Fish"-skript for å identifisere ikke-unike poster ved hjelp av SQL:
VELG COUNT(*)-teller,<перечисление всех полей соответствующего индекса>fra<имя таблицы>
GRUPPE AV<перечисление всех полей соответствующего индекса>
Å HA Teller > 1

2.2.2 Eksempel. Indeksen i feilen heter "_Document140_VT1385_IntKeyIndNG".

Liste over tabellfelt:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_FlRe3, _FldRe3, _FldRe3, _FldRe3, _Fld Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_Fld22261_Fld22261_Fld22261_1 _RRRef

Før du utfører prosedyren nedenfor, må du sikkerhetskopiere databasen.
Kjør i MS SQL Server Query Analyzer:

velg antall(*), _Document140_IDRRef, _KeyField
from_Document140_VT1385
grupper etter _Document140_IDRRef, _KeyField
har telling(*) > 1

Bruk den til å finne ut verdiene til kolonnene _Document140_IDRRef, _KeyField, duplikatposter (id, nøkkel).

Ved å bruke forespørselen:

plukke ut *
from_Document140_VT1385
eller _Document140_IDRRef = id2 og _KeyField = nøkkel2 eller …

se på verdiene til de andre kolonnene i de dupliserte oppføringene.

Hvis begge oppføringene har meningsfulle verdier og verdiene er forskjellige, endrer du _KeyField-verdien til å være unik. For å gjøre dette, bestem den maksimale okkuperte verdien for _KeyField (keymax):

velg max(_KeyField)
from_Document140_VT1385
hvor _Dokument140_IDRRef = id1

Erstatt _KeyField-verdien i en av de dupliserte oppføringene med den riktige:

update_Document140_VT1385
sett _KeyField = keymax + 1

Her er _LineNo1386 = en tilleggsbetingelse som lar deg velge en av to gjentatte poster.

Hvis en (eller begge) av de dupliserte oppføringene har en åpenbart feil betydning, bør den fjernes:

der _Document140_IDRRef = id1 og _LineNo1386 = lineno1

Hvis dupliserte oppføringer har samme verdier i alle kolonner, må du forlate en av dem:

velg distinkt *
inn i #tmp1
from_Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

slett fra _Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

sett inn i _Document140_VT1385
velg #tmp1

slipp tabell #tmp1

Den beskrevne prosedyren må utføres for hvert par dupliserte poster.

2.2.3. Andre eksempel:

VELG ANTALL(*) AS Uttr2, _IDRRef AS Uttr1, _Beskrivelse
FRA _Referanse8_
GRUPPE ETTER _IDRRef, _Beskrivelse
HAR (COUNT(*) > 1)

2.3.4 Et eksempel på å bestemme ikke-unike poster ved å bruke en 1C:Enterprise-spørring:

eller for regnskap

VELGE
Subquery.Period,
Subquery.Registrator,
<измерения>,
SUM(Subquery.Number of Records) AS Antall poster
FRA
(VELGE
Selvforsørgende Periode AS Periode,
Self-supporting.Registrar AS Registrar,
<измерения>,
1 AS Antall poster
FRA
Regnskapsregister. Selvbærende AS Selvbærende) AS Underspørring

GRUPPE AV
Subquery.Period,
Subquery.Registrator,
<измерения>

HA
SUM(Subquery.Number of Records) > 1

2.3.5 Gjør subd-indeksen ikke-unik. Skriv indeksen med Management Studio.

2.3.6 Et spesielt tilfelle ved utveksling i RDB. Feilen oppstår i "hjelpetabeller" knyttet til beregning av totaler eller analyser. For eksempel:

Feil ved oppkalling av kontekstmetoden (Skriv): Forsøk på å sette inn en ikke-unik verdi i en unik indeks:
Microsoft OLE DB Provider for SQL Server: Kan ikke sette inn duplikatnøkkelrad i objektet 'dbo._AccntRegED10319' med den unike indeksen '_Accnt10319_ByPeriod_TRNRN'.
HRESULT=80040E2F, SQLSrvr: Feilstatus=1, Alvorlighet=E, opprinnelig=2601, linje=1

I dette tilfellet, før lasting, slå av bruken av totaler, last inn meldingen, aktiver bruk av totaler og regn på nytt.

Løsninger:

2. 1) Ved å bruke Management Studio 2005 genererte jeg et opprettelsesskript for å lage en indeks, som var buggy, og lagret den i en fil.
2) manuelt drept jamb-indeksen fra tabellen _AccumRgTn19455
3) Lanserte en forespørsel som
SQL-kode S_elect count(*), indeksfelter
FR OM AccumRgTn19455
GRUPPER ETTER indeksfelt
HAR telling(*)>1
Etter at indeksen ble drept, hadde jeg 15 dupliserte poster vist, men før trinn 2 returnerte ikke spørringen noe.
4) Jeg gikk gjennom alle oppføringene og ryddet opp i duplikater manuelt. Faktisk brukte jeg også "Rapportstruktur"-behandlingen for å forstå hva jeg hadde å gjøre med. Det viste seg at tabellen _AccumRgTn19455 lagrer akkumuleringsregisteret "Produktutgang (skatteregnskap)". Jeg fiklet også med sql-spørringer, identifiserte 15 ikke-unike dokumenter, og etter at alle handlingene var fullført, sjekket jeg i 1C at disse dokumentene ble behandlet normalt, uten feil. Selvfølgelig bør du ikke bare rengjøre bord tilfeldig: det er viktig å forstå hva som blir rengjort og hvordan det kan slå ut.
5) Lanserte en forespørsel om å opprette en indeks, som ble lagret i en fil.
6) Byttet databasen til enkeltbrukermodus og startet dbcc checkdb - denne gangen ble det ikke generert noen feil.
7) Byttet basen tilbake til enkeltbrukermodus.
Det er det... problemet er overvunnet. Vel, tilbake i 1C lanserte jeg "Testing og korrigering", alt gikk bra der også, jeg sluttet å klage på den ikke-unike indeksen.

3. Hvis ikke-unikken ligger i datoer med nullverdier, så løses problemet ved å lage en database med en offset-parameter lik 2000.

1.2. Hvis det er mulig å jobbe med databasen i filversjonen, så utfør Testing og Korreksjon, samt Konfigurasjon - Sjekke konfigurasjonen - Kontrollere den logiske integriteten til konfigurasjonen + Søke etter feil lenker.

2. Hvis problemet med ikke-unikhet oppstår mens brukere jobber:

2.1. Finn den problematiske forespørselen ved å bruke metoden i avsnitt 1.4.

2.1.2. Noen ganger oppstår det en feil under utføring av spørringer, for eksempel:

Denne feilen oppstår på grunn av det faktum at i akkumuleringsregistermodulen "Arbeidstid for ansatte i organisasjoner" i prosedyren "Register Recalculations" er ikke tjenesteordet "DIFFERENENT" inkludert i forespørselen.
Kode 1C v 8.x Dvs. bør være:
Request = New Request(
"VELG DIVERSE
| Basic.Individuell,
. . . . .
I de siste utgivelsene av ZUP og UPP oppstår ikke feilen, fordi det står "ANNERLEDES".

2.2.2 Eksempel. Indeksen i feilen heter "_Document140_VT1385_IntKeyIndNG".
Liste over tabellfelt:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld13_3_Ref1393_Ref1393_Fld1393_Ref1393 f, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_Fld22260_Fld22260_1_FldRef,2_FldRef,2_FldRef, 6_FldRef f, _Fld22261_RRRef
Før du utfører prosedyren nedenfor, må du sikkerhetskopiere databasen.
Kjør i MS SQL Server Query Analyzer:
SQL-kode S_elect count(*), _Document140_IDRRef, _KeyField
fra om _Document140_VT1385
grupper etter _Document140_IDRRef, _KeyField
har telling(*) > 1
Bruk den til å finne ut verdiene til kolonnene _Document140_IDRRef, _KeyField, duplikatposter (id, nøkkel).

Ved å bruke forespørselen:
SQL-kode S_elect *
fra om _Document140_VT1385
der _Document140_IDRRef = id1 og _KeyField = key1 eller _Document140_IDRRef = id2 og _KeyField = key2 eller ...
se på verdiene til de andre kolonnene i de dupliserte oppføringene.
Hvis begge oppføringene har meningsfulle verdier og verdiene er forskjellige, endrer du _KeyField-verdien til å være unik. For å gjøre dette, bestem den maksimale okkuperte verdien for _KeyField (keymax):
SQL-kode S_elect max(_KeyField)
fra om _Document140_VT1385
hvor _Dokument140_IDRRef = id1
Erstatt _KeyField-verdien i en av de dupliserte oppføringene med den riktige:
SQL-kode oppdatert _Document140_VT1385
sett _KeyField = keymax + 1

Her er _LineNo1386 = en tilleggsbetingelse som lar deg velge en av to gjentatte poster.

Hvis en (eller begge) av de dupliserte oppføringene har en åpenbart feil betydning, bør den fjernes:
SQL-kodesletting fra _Document140_VT1385
hvor _Document140_IDRRef = id1 og _LineNo1386 = lineno1
Hvis dupliserte oppføringer har samme verdier i alle kolonner, må du forlate en av dem:
SQL-kode S_elect distinkt *
inn i #tmp1
from_Document140_VT1385

Slett fra _Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

I_sert inn i _Document140_VT1385
S_velg #tmp1

D_rop-tabell #tmp1

Den beskrevne prosedyren må utføres for hvert par dupliserte poster.

2.2.3. Andre eksempel:
SQL Code S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRA _Referanse8_
GRUPPE ETTER _IDRRef, _Beskrivelse
HAR (COUNT(*) > 1)

Informasjon hentet fra siden

Løsninger:

2. 1) Ved å bruke Management Studio 2005 genererte jeg et opprettelsesskript for å lage en indeks, som var buggy, og lagret den i en fil.
2) manuelt drept jamb-indeksen fra tabellen _AccumRgTn19455
3) Lanserte en forespørsel som
SQL-kode S_elect count(*), indeksfelter
FRA AccumRgTn19455
GRUPPER ETTER indeksfelt
HAR telling(*)>1
Etter at indeksen ble drept, hadde jeg 15 dupliserte poster vist, men før trinn 2 returnerte ikke spørringen noe.
4) Jeg gikk gjennom alle oppføringene og ryddet opp i duplikater manuelt. Faktisk brukte jeg også "Rapportstruktur"-behandlingen for å forstå hva jeg hadde å gjøre med. Det viste seg at tabellen _AccumRgTn19455 lagrer akkumuleringsregisteret "Produktutgang (skatteregnskap)". Jeg pirket også med sql-spørringer, identifiserte 15 ikke-unike dokumenter, og etter at alle handlingene var fullført, sjekket jeg i 1C at disse dokumentene ble behandlet normalt, uten feil. Selvfølgelig bør du ikke bare rengjøre bord tilfeldig: det er viktig å forstå hva som blir rengjort og hvordan det kan slå ut.
5) Lanserte en forespørsel om å opprette en indeks, som ble lagret i en fil.
6) Byttet databasen til enkeltbrukermodus og startet dbcc checkdb - denne gangen ble det ikke generert noen feil.
7) Byttet basen tilbake til enkeltbrukermodus.
Det er det... problemet er overvunnet. Vel, tilbake i 1C lanserte jeg "Testing og korrigering", alt gikk bra der også, jeg sluttet å klage på den ikke-unike indeksen.

3. Hvis ikke-unikken ligger i datoer med nullverdier, så løses problemet ved å lage en database med en offset-parameter lik 2000.

2. Hvis problemet med ikke-unikhet oppstår mens brukere jobber:

2.1. Finn den problematiske forespørselen ved å bruke metoden i avsnitt 1.4.

2.1.2. Noen ganger oppstår det en feil under utføring av spørringer, for eksempel:

Denne feilen oppstår på grunn av det faktum at i akkumuleringsregistermodulen "Arbeidstid for ansatte i organisasjoner" i prosedyren "Register Recalculations" er ikke tjenesteordet "DIFFERENENT" inkludert i forespørselen.
Kode 1C v 8.x Dvs. bør være:
Request = New Request(
"VELG DIVERSE
| Basic.Individual,
. . . . .
I de siste utgivelsene av ZUP og UPP oppstår ikke feilen, fordi det står "ANNERLEDES".

2.2.2 Eksempel. Indeksen i feilen heter "_Document140_VT1385_IntKeyIndNG".
Liste over tabellfelt:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld13_3_Ref1393_Ref1393_Fld1393_Ref1393 f, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_Fld22260_Fld22260_1_FldRef,2_FldRef,2_FldRef, 6_FldRef f, _Fld22261_RRRef
Før du utfører prosedyren nedenfor, må du sikkerhetskopiere databasen.
Kjør i MS SQL Server Query Analyzer:
SQL-kode S_elect count(*), _Document140_IDRRef, _KeyField
from_Document140_VT1385
grupper etter _Document140_IDRRef, _KeyField
har telling(*) > 1
Bruk den til å finne ut verdiene til kolonnene _Document140_IDRRef, _KeyField, duplikatposter (id, nøkkel).

Slett fra _Document140_VT1385
hvor _Document140_IDRRef = id1 og _KeyField = nøkkel1

I_sert inn i _Document140_VT1385
S_velg #tmp1

D_rop-tabell #tmp1

Den beskrevne prosedyren må utføres for hvert par dupliserte poster.

2.2.3. Andre eksempel:
SQL Code S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRA _Referanse8_
GRUPPE ETTER _IDRRef, _Beskrivelse
HAR (COUNT(*) > 1)

Populært i kategorien: