3.0 60.59 fel när ett icke-unikt värde infogas. Ett försök gjordes att infoga ett icke-unikt värde i ett unikt index. Vad är ett index

Du har fått ett meddelande som innehåller raderna:
Microsoft OLE DB Provider för SQL Server: CREATE UNIQUE INDEX avslutades eftersom en dubblettnyckel hittades för index-ID
eller
Det går inte att lägga in dubblettnyckelrad i objektet
eller
Ett försök gjordes att infoga ett icke-unikt värde i ett unikt index.

Lösningar:

1. I SQL Server managment studio förstör vi fysiskt det felaktiga indexet (i mitt fall var det ett index på redovisningsregistrets totaltabell). I 1C kommer vi att distribuera de felaktiga dokumenten. I test- och korrigeringsläge, markera rutorna för tabellomindexering + omräkning av totaler. 1C återskapar indexet utan fel. Vi utför tidigare misslyckade dokument.

2. 1) Med Management Studio 2005 skapade jag ett skapa-skript för att skapa ett index, som var buggigt, och sparade det i en fil.
2) Manuellt dödade jamb-indexet från tabellen _AccumRgTn19455
3) Lanserade en begäran som
SQL-kod S_elect count(*), index_fields
FR OM AccumRgTn19455
GROUP BY index_field
HA räkning(*)>1
Efter att indexet dödades visades 15 dubbletter av poster, men före steg 2 returnerade frågan ingenting.
4) Jag gick igenom alla poster och rensade manuellt upp dubbletter. Faktum är att jag också använde bearbetningen "Rapportstruktur" för att förstå vad jag hade att göra med. Det visade sig att tabellen _AccumRgTn19455 lagrar ackumuleringsregistret "Produktutdata (skatteredovisning)". Jag pysslade också med sql-frågor, identifierade 15 icke-unika dokument, och efter att alla åtgärder var slutförda kontrollerade jag i 1C att dessa dokument behandlades normalt, utan fel. Naturligtvis ska du inte bara rengöra bord på måfå: det är viktigt att förstå vad som städas och hur det kan bli.
5) Startade en begäran om att skapa ett index, som sparades i en fil.
6) Bytte databasen till enanvändarläge och startade dbcc checkdb - den här gången genererades inga fel.
7) Växlade tillbaka basen till enanvändarläge.
Det är det... problemet är löst. Tja, tillbaka i 1C lanserade jag "Testning och korrigering", allt gick bra där också, jag slutade klaga på det icke-unika indexet.

3. Om icke-unikheten ligger i datum med nollvärden, då löses problemet genom att skapa en databas med en offsetparameter lika med 2000.

1. Om problemet är att ladda databasen:
1.1. Om du laddar (med en dt-fil) till en MS SQL Server-databas, när du skapar databasen, innan du laddar, ange datumförskjutningen - 2000.
Om databasen redan har skapats med offset 0, skapa en ny med 2000.

1.2. Om det är möjligt att arbeta med databasen i filversionen, utför då Testning och Korrigering, samt Konfiguration - Kontrollera konfigurationen - Kontrollera konfigurationens logiska integritet + Sök efter felaktiga länkar.

1.3. Om det inte finns någon filversion, prova att ladda från DT till en klient-serverversion med DB2 (vilket kräver mindre unikhet) och utför sedan Test och korrigering, samt Konfiguration - Verifiera konfiguration - Kontrollera konfigurationens logiska integritet + Sök efter ogiltiga referenser.

1.4. För att lokalisera problemet kan du bestämma data för objektet vars laddning misslyckades. För att göra detta måste du aktivera spårning i Profiler-verktyget under uppstart eller aktivera inspelning i DBMSSQL- och EXCP-processhändelseloggen.

2. Om det icke-unika problemet uppstår medan användare arbetar:

2.1. Hitta den problematiska begäran med metoden i punkt 1.4.

2.1.2. Ibland uppstår ett fel när frågor körs, till exempel:

Det här felet uppstår på grund av det faktum att i ackumuleringsregistermodulen "Arbetstid för anställda i organisationer" i proceduren "Registrera omberäkningar" ingår inte serviceordet "ANNÄRA" i begäran.
Kod 1C v 8.x Dvs. borde vara:
Request = New Request(
"VÄLJ OLIKA
| Basic.Individuell,
. . . . .
I de senaste versionerna av ZUP och UPP uppstår inte felet, eftersom det står "ANNARNA".

2.2. Efter att ha hittat det problematiska indexet från föregående stycke måste du hitta en icke-unik post.
2.2.1. "Fish"-skript för att identifiera icke-unika poster med SQL:
SQL-kod S_elect COUNT(*) Counter,<перечисление всех полей соответствующего индекса>från<имя таблицы>
GRUPP AV<перечисление всех полей соответствующего индекса>
ATT HA räknare > 1

2.2.2 Exempel. Indexet i felet heter "_Document140_VT1385_IntKeyIndNG".
Lista över tabellfält:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld139_Ref, _Fld139_3_Fld13, 3_Fld RRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _FldRR_222,1d_FldRef_222,1d _RTRef, _Fld22261_RRRef
Innan du utför proceduren nedan, säkerhetskopiera din databas.
Kör i MS SQL Server Query Analyzer:
SQL-kod S_elect count(*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
grupp av _Document140_IDRRef, _KeyField
har count(*) > 1
Använd den för att ta reda på värdena för kolumnerna _Document140_IDRRef, _KeyField, dubbletter av poster (id, nyckel).

Använda begäran:
SQL-kod S_elect *
fr om _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1 eller _Document140_IDRRef = id2 och _KeyField = nyckel2 eller ...
titta på värdena för de andra kolumnerna i dubblettposterna.
Om båda posterna har meningsfulla värden och värdena är olika, ändra sedan _KeyField-värdet till att vara unikt. För att göra detta, bestäm det maximala ockuperade värdet för _KeyField (keymax):
SQL-kod S_elect max(_KeyField)
fr om _Document140_VT1385
där _Dokument140_IDRRef = id1
Ersätt _KeyField-värdet i en av dubblettposterna med den korrekta:
SQL-kod uppdaterad _Document140_VT1385
ställ in _KeyField = keymax + 1

Här är _LineNo1386 = ett ytterligare villkor som låter dig välja en av två upprepade poster.

Om en (eller båda) av dubblettposterna har en uppenbart felaktig betydelse, bör den tas bort:
SQL-kod radering från _Document140_VT1385
där _Document140_IDRRef = id1 och _LineNo1386 = lineno1
Om dubbla poster har samma värden i alla kolumner, måste du lämna en av dem:
SQL-kod S_elect distinkt *
till #tmp1
från _Document140_VT1385

Ta bort från _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1

I_sert in i _Document140_VT1385
S_välj #tmp1

D_rop-tabell #tmp1

Den beskrivna proceduren måste utföras för varje par av dubbletter av poster.

2.2.3. Andra exemplet:
SQL-kod S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRÅN _Referens8_
GROUP BY _IDRRef, _Description
HAR (ANTAL(*) > 1)

2.3.4 Ett exempel på att fastställa icke-unika poster med en 1C:Enterprise-fråga:
Kod 1C v 8.x SELECT Directory.Link
FRÅN Directory.Directory AS Directory
GROUP BY Directory.Link
HAR KVANTITY(*) > 1

Information hämtad från sajten

Lösningar:

1. I SQL Server managment studio förstör vi fysiskt det felaktiga indexet (i mitt fall var det ett index pån). I 1C kommer vi att distribuera de felaktiga dokumenten. I test- och korrigeringsläge, markera rutorna för tabellomindexering + omräkning av totaler. 1C återskapar indexet utan fel. Vi utför tidigare misslyckade dokument.

2. 1) Med Management Studio 2005 skapade jag ett skapa-skript för att skapa ett index, som var buggigt, och sparade det i en fil.
2) Manuellt dödade jamb-indexet från tabellen _AccumRgTn19455
3) Lanserade en begäran som
SQL-kod S_elect count(*), index_fields
FRÅN AccumRgTn19455
GROUP BY index_field
HA räkning(*)>1
Efter att indexet dödades visades 15 dubbletter av poster, men före steg 2 returnerade frågan ingenting.
4) Jag gick igenom alla poster och rensade manuellt upp dubbletter. Faktum är att jag också använde bearbetningen "Rapportstruktur" för att förstå vad jag hade att göra med. Det visade sig att tabellen _AccumRgTn19455 lagrar ackumuleringsregistret "Produktutdata (skatteredovisning)". Jag pysslade också med sql-frågor, identifierade 15 icke-unika dokument, och efter att alla åtgärder var slutförda kontrollerade jag i 1C att dessa dokument behandlades normalt, utan fel. Naturligtvis ska du inte bara rengöra bord på måfå: det är viktigt att förstå vad som städas och hur det kan bli.
5) Startade en begäran om att skapa ett index, som sparades i en fil.
6) Bytte databasen till enanvändarläge och startade dbcc checkdb - den här gången genererades inga fel.
7) Växlade tillbaka basen till enanvändarläge.
Det är det... problemet är löst. Tja, tillbaka i 1C lanserade jag "Testning och korrigering", allt gick bra där också, jag slutade klaga på det icke-unika indexet.

3. Om icke-unikheten ligger i datum med nollvärden, då löses problemet genom att skapa en databas med en offsetparameter lika med 2000.

2. Om det icke-unika problemet uppstår medan användare arbetar:

2.1. Hitta den problematiska begäran med metoden i punkt 1.4.

2.1.2. Ibland uppstår ett fel när frågor körs, till exempel:

2.2.2 Exempel. Indexet i felet heter "_Document140_VT1385_IntKeyIndNG".
Lista över tabellfält:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld139_Ref, _Fld139_3_Fld13, 3_Fld RRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _FldRR_222,1d_FldRef_222,1d _RTRef, _Fld22261_RRRef
Innan du utför proceduren nedan, säkerhetskopiera din databas.
Kör i MS SQL Server Query Analyzer:
SQL-kod S_elect count(*), _Document140_IDRRef, _KeyField
från _Document140_VT1385
grupp av _Document140_IDRRef, _KeyField
med count(*) > 1
Använd den för att ta reda på värdena för kolumnerna _Document140_IDRRef, _KeyField, dubbletter av poster (id, nyckel).

Använda begäran:
SQL-kod S_elect *
från _Document140_VT1385
eller _Document140_IDRRef = id2 och _KeyField = nyckel2 eller ...
titta på värdena för de andra kolumnerna i dubblettposterna.
Om båda posterna har meningsfulla värden och värdena är olika, ändra sedan _KeyField-värdet till att vara unikt. För att göra detta, bestäm det maximala ockuperade värdet för _KeyField (keymax):
SQL-kod S_elect max(_KeyField)
från _Document140_VT1385
där _Dokument140_IDRRef = id1
Ersätt _KeyField-värdet i en av dubblettposterna med den korrekta:
SQL-koduppdatering _Document140_VT1385
ställ in _KeyField = keymax + 1
Här är _LineNo1386 = ett ytterligare villkor som låter dig välja en av två upprepade poster.

Ta bort från _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1

I_sert in i _Document140_VT1385
S_välj #tmp1

D_rop-tabell #tmp1

Den beskrivna proceduren måste utföras för varje par av dubbletter av poster.

2.2.3. Andra exemplet:
SQL-kod S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRÅN _Referens8_
GROUP BY _IDRRef, _Description
HAR (ANTAL(*) > 1)

Den här artikeln kommer att beskriva vad du ska göra om du, när du arbetar med 1C:Enterprise 8.1, stöter på ett meddelande som innehåller raderna:

Det går inte att infoga duplicerad nyckelrad i objektet

Ett försök gjordes att infoga ett icke-unikt värde i ett unikt index.

Vad är ett index?

Index är en struktur som tillåter snabb åtkomst till rader i en tabell baserat på värdena i en eller flera av dess kolumner.
Ett index innehåller nycklar, byggda från en eller flera kolumner i en tabell eller vy, och pekare som mappar till var den angivna informationen lagras.
Index minskar mängden data som måste läsas för att returnera en resultatuppsättning.

Även om ett index är associerat med en specifik kolumn (eller kolumner) i en tabell, är det fortfarande ett separat databasobjekt.

Index av tabeller i 1C:Enterprise-databasen skapas implicit när man skapar konfigurationsobjekt, såväl som under vissa inställningar av konfigurationsobjekt.

Den fysiska essensen av index i MS SQL Server 2005.

Fysiskt lagras uppgifterna på 8Kb sidor. Omedelbart efter skapandet, medan tabellen inte har index, ser tabellen ut som en hög med data. Poster har ingen specifik lagringsordning.
När du vill komma åt data kommer SQL Server att producera tabellskanning(tabellskanning). SQL Server skannar hela tabellen för att hitta de poster den letar efter.
Härifrån blir indexens grundläggande funktioner tydliga:
— öka hastigheten för dataåtkomst,
— Stöd för unika data.

Trots sina fördelar har index också ett antal nackdelar. Den första är index ta upp ytterligare diskutrymme och i RAM. Varje gång du skapar ett index lagrar du nycklarna i fallande eller stigande ordning, som kan ha en struktur på flera nivåer. Och ju större/längre nyckel, desto större indexstorlek. Den andra nackdelen är verksamheten saktar ner infoga, uppdatera och radera poster.
I MS SQL Server 2005-miljön är flera typer av index implementerade:

icke-klustrade index;
klustrade (eller klustrade) index;
unika index;
index med inkluderade kolumner
indexerade vyer
Full text

Unikt index

Det unika hos värdena i den indexerade kolumnen garanteras av unika index. Om de finns kommer servern inte att tillåta dig att infoga ett nytt värde eller ändra ett befintligt värde på ett sådant sätt att två identiska värden visas i kolumnen som ett resultat av denna operation.
Ett unikt index är ett slags tillägg och kan implementeras för både klustrade och icke-klustrade index. En tabell kan ha ett unikt klustrat index och många unika icke-klustrade index.
Unika index bör endast definieras när det verkligen är nödvändigt. För att säkerställa dataintegritet på en kolumn kan du definiera en UNIK eller PRIMÄR KEY integritetsbegränsning snarare än att tillgripa unika index. Att använda dem enbart för att säkerställa dataintegritet är ett slöseri med databasutrymme. Dessutom läggs CPU-tid på underhållet.

1C:Enterprise 8.1, från och med version 8.1, använder aktivt klustrade unika index. Detta betyder att när du konverterar från 8.0 eller migrerar från 8.1.7 kan du få ett icke-unikt indexfel.

Om icke-unikiteten ligger i datum med nollvärden, löses problemet genom att skapa en databas med en offsetparameter lika med 2000.

Vad ska man göra?

1. Om problemet är att ladda databasen:

1.1. Om du laddar (med en dt-fil) till en MS SQL Server-databas, när du skapar databasen, innan du laddar, ange datumförskjutningen - 2000.

Om databasen redan har skapats med offset 0, skapa en ny med 2000.

1.5. Om noden (utbytesplanerna) är tillgänglig, utför sedan bytet. Du kan också komplettera avsnitt 2.3.5 innan du byter

2. Om det icke-unika problemet uppstår medan användare arbetar:

2.1. Hitta den problematiska begäran med metoden i punkt 1.4.

2.1.2. Ibland uppstår ett fel när frågor körs, till exempel:

De där. borde vara:

Request = New Request(
"VÄLJ OLIKA
| Basic.Individuell,

I de senaste versionerna av ZUP och UPP uppstår inte felet, eftersom det står "ANNARNA".

2.2. Efter att ha hittat det problematiska indexet från föregående stycke måste du hitta en icke-unik post.

2.2.1. "Fish"-skript för att identifiera icke-unika poster med SQL:
VÄLJ COUNT(*)-räknare,<перечисление всех полей соответствующего индекса>från<имя таблицы>
GRUPP AV<перечисление всех полей соответствующего индекса>
ATT HA räknare > 1

2.2.2 Exempel. Indexet i felet heter "_Document140_VT1385_IntKeyIndNG".

Lista över tabellfält:

Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_RTRe39, _Fld1393_RTRe39, _Fld _Fld1394,

Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_Fld22261_Fld22261 1_RRRef

Innan du utför proceduren nedan, säkerhetskopiera din databas.
Kör i MS SQL Server Query Analyzer:

välj count(*), _Document140_IDRRef, _KeyField
från _Document140_VT1385
grupp av _Document140_IDRRef, _KeyField
har count(*) > 1

Använd den för att ta reda på värdena för kolumnerna _Document140_IDRRef, _KeyField, dubbletter av poster (id, nyckel).

Använda begäran:

Välj *
från _Document140_VT1385
eller _Document140_IDRRef = id2 och _KeyField = nyckel2 eller …

titta på värdena för de andra kolumnerna i dubblettposterna.

Om båda posterna har meningsfulla värden och värdena är olika, ändra sedan _KeyField-värdet till att vara unikt. För att göra detta, bestäm det maximala ockuperade värdet för _KeyField (keymax):

välj max(_KeyField)
från _Document140_VT1385
där _Dokument140_IDRRef = id1

Ersätt _KeyField-värdet i en av dubblettposterna med den korrekta:

update_Document140_VT1385
ställ in _KeyField = keymax + 1

Här är _LineNo1386 = ett ytterligare villkor som låter dig välja en av två upprepade poster.

Om en (eller båda) av dubblettposterna har en uppenbart felaktig betydelse, bör den tas bort:

där _Document140_IDRRef = id1 och _LineNo1386 = lineno1

Om dubbla poster har samma värden i alla kolumner, måste du lämna en av dem:

välj distinkt *
till #tmp1
från _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1

radera från _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1

infoga i _Document140_VT1385
välj #tmp1

släpp tabell #tmp1

Den beskrivna proceduren måste utföras för varje par av dubbletter av poster.

2.2.3. Andra exemplet:

VÄLJ ANTAL(*) AS Expr2, _IDRRef AS Expr1, _Description
FRÅN _Referens8_
GROUP BY _IDRRef, _Description
HAR (ANTAL(*) > 1)

2.3.4 Ett exempel på att fastställa icke-unika poster med en 1C:Enterprise-fråga:

eller för bokföring

VÄLJA
Subquery.Period,
Subquery.Recorder,
<измерения>,
SUM(Subquery.Number of Records) AS Antal poster
FRÅN
(VÄLJA
Självförsörjande Period AS Period,.
Self-supporting.Registrar AS Registrar,
<измерения>,
1 AS Antal poster
FRÅN
Redovisningsregister Self-supporting AS Self-supporting) AS Subquery

GRUPP AV
Subquery.Period,
Subquery.Recorder,
<измерения>

HAR
SUM(Subquery.Number of Records) > 1

2.3.5 Gör subd-indexet ounikt. Skripta indexet med Management Studio.

2.3.6 Ett specialfall vid utbyte i RDB. Felet uppstår i "hjälptabeller" förknippade med beräkningen av totaler eller analyser. Till exempel:

Fel vid anrop av kontextmetoden (skriv): Försök att infoga ett icke-unikt värde i ett unikt index:
Microsoft OLE DB Provider för SQL Server: Kan inte infoga dubblettnyckelrad i objektet 'dbo._AccntRegED10319' med unikt index '_Accnt10319_ByPeriod_TRNRN'.
HRESULT=80040E2F, SQLSrvr: Error state=1, Severity=E, native=2601, line=1

I det här fallet, innan du laddar, stäng av användningen av totaler, ladda meddelandet, aktivera användningen av totaler och beräkna om.

Lösningar:

2. 1) Med Management Studio 2005 skapade jag ett skapa-skript för att skapa ett index, som var buggigt, och sparade det i en fil.
2) Manuellt dödade jamb-indexet från tabellen _AccumRgTn19455
3) Lanserade en begäran som
SQL-kod S_elect count(*), index_fields
FRÅN AccumRgTn19455
GROUP BY index_field
HA räkning(*)>1
Efter att indexet dödades visades 15 dubbletter av poster, men före steg 2 returnerade frågan ingenting.
4) Jag gick igenom alla poster och rensade manuellt upp dubbletter. Faktum är att jag också använde bearbetningen "Rapportstruktur" för att förstå vad jag hade att göra med. Det visade sig att tabellen _AccumRgTn19455 lagrar ackumuleringsregistret "Produktutdata (skatteredovisning)". Jag pysslade också med sql-frågor, identifierade 15 icke-unika dokument, och efter att alla åtgärder var slutförda kontrollerade jag i 1C att dessa dokument behandlades normalt, utan fel. Naturligtvis ska du inte bara rengöra bord på måfå: det är viktigt att förstå vad som städas och hur det kan bli.
5) Startade en begäran om att skapa ett index, som sparades i en fil.
6) Bytte databasen till enanvändarläge och startade dbcc checkdb - den här gången genererades inga fel.
7) Växlade tillbaka basen till enanvändarläge.
Det är det... problemet är löst. Tja, tillbaka i 1C lanserade jag "Testning och korrigering", allt gick bra där också, jag slutade klaga på det icke-unika indexet.

3. Om icke-unikheten ligger i datum med nollvärden, då löses problemet genom att skapa en databas med en offsetparameter lika med 2000.

2. Om det icke-unika problemet uppstår medan användare arbetar:

2.1. Hitta den problematiska begäran med metoden i punkt 1.4.

2.1.2. Ibland uppstår ett fel när frågor körs, till exempel:

2.2.2 Exempel. Indexet i felet heter "_Document140_VT1385_IntKeyIndNG".
Lista över tabellfält:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld139_Ref, _Fld139_3_Fld13, 3_Fld RRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _FldRR_222,1d_FldRef_222,1d _RTRef, _Fld22261_RRRef
Innan du utför proceduren nedan, säkerhetskopiera din databas.
Kör i MS SQL Server Query Analyzer:
SQL-kod S_elect count(*), _Document140_IDRRef, _KeyField
från _Document140_VT1385
grupp av _Document140_IDRRef, _KeyField
med count(*) > 1
Använd den för att ta reda på värdena för kolumnerna _Document140_IDRRef, _KeyField, dubbletter av poster (id, nyckel).

Ta bort från _Document140_VT1385
där _Document140_IDRRef = id1 och _KeyField = nyckel1

I_sert in i _Document140_VT1385
S_välj #tmp1

D_rop-tabell #tmp1

Den beskrivna proceduren måste utföras för varje par av dubbletter av poster.

2.2.3. Andra exemplet:
SQL-kod S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
FRÅN _Referens8_
GROUP BY _IDRRef, _Description
HAR (ANTAL(*) > 1)

Ett fel uppstår om vissa objekt, detaljer, subcontos i databasen har ett NULL-värde, men de kan inte ha ett sådant värde. Och detta fel visas bara i SQL-databaser. De där. Om du laddar upp en sådan databas till en fil ett, kommer detta fel inte längre att finnas där. Därför att Fildatabasen har sina egna tabeller (4 totalt), och SQL har sina egna. Och SQL-databasen reagerar kritiskt på sådana värden i sina tabeller.

Detta problem kan inte lösas genom någon testning (varken extern eller intern) i någon version av databasen (SQL eller fil) och till och med genom _1sp_DBReindex-proceduren i SQL-hanteraren, som verkar vara tänkt att omstrukturera tabeller i SQL.

Låt oss titta på lösningen på problemet med exemplet att byta från Accounting 3.0 PROF till CORP. Efter övergången har konto 68.01 ett nytt underkonto, Registrering hos Skatteverket. Och sedan, i SQL-databaser, kommer inte alla dokument som skapats i PRO-versionen som använder detta konto att överföras. Felet som visas ovan visas. Därför att Detta nya underkonto för gamla dokument, i bokföringar, kommer att skrivas med värdet NULL (även om det borde finnas ett tomt värde, eller på något sätt skattemyndigheten).

För att åtgärda detta fel måste du ta bort NULL-värden där de inte borde finnas. I detta fall i handlingar där subconto Registrering hos Skatteverket används. Detta kan göras genom att skriva en bearbetning som kommer att ersätta NULL med ett Empty-värde (färdig bearbetning kan laddas ner från den här artikeln). Gör det genom att bearbeta, eftersom Ett försök att ändra värdet på detta underkonto manuellt i dokumentbokningar resulterar i samma fel.

Behandling för att ersätta NULL i alla underkontakter till Registrering hos Skattemyndigheten kan laddas ner från denna artikel nedan.

MEN det kommer inte att fungera att ersätta NULL i SQL-databasen under bearbetning kommer samma fel att genereras. Därför måste du göra detta:

1. Ladda upp den redan fungerande versionen av SQL-databasen, översatt till CORP, till dt-filen (i konfiguratorn Administration – Ladda upp databas – välj var du vill ladda upp databasen som en *.dt-fil)

2. Ladda dt-filen i fildatabasen (i en onödig eller förberedd, ren fildatabas, i konfiguratorn Administration - Ladda databas - välj den tidigare uppladdade dt-filen)

3. Utför bearbetning i fildatabasen (det blir inga fel där och alla NULLs kommer att ersättas korrekt) (hur man utför bearbetning beskrivs nedan)

5. Nu, tvärtom, ladda ur dt-filen från fildatabasen och ladda in den i SQL-databasen. Nu, när du bokför bearbetade dokument, kommer inga fel att uppstå.

Bearbetningen från denna artikel hittar alla dokument för den angivna perioden under vilken inläggen inkluderar underleverantörsregistrering hos Skattemyndigheten (som förekommer i CORP-versionen), som har värdet NULL. Och ersätter detta värde med ett tomt värde.

I behandlingen måste du ange för vilken period du vill behandla dokumenten (du kan under hela den period som register sparas i databasen) och klicka på "Fyll i tabelldelen." Sedan kan du markera rutorna för att markera vilka dokument som ska behandlas (du kan välja alla) och klicka på knappen "Bearbeta".

Följaktligen, om någon har samma fel, men INTE efter att ha bytt till CORP, utan till exempel efter att ha utbytt, laddat vissa data, utfört viss bearbetning, etc. Sedan måste du identifiera var NULL-värdet tilldelades i ett specifikt dokument/katalog och ta bort denna NULL på liknande sätt, men med din egen bearbetning, men i den ordning som beskrivs ovan. Kom ihåg att NULL kan vara, som vid dokumentposteringar, inkl. inte bara redovisning, utan också någonstans i form av ett dokument/uppslagsbok, i vissa detaljer, men i det här fallet kommer det förmodligen inte ens att öppnas.

Dessutom, om det här felet uppenbarade sig för dig när du postade ett dokument, efter att du överförde Bukh KORP-fildatabasen till SQL (och databasen en gång ursprungligen var PROF), betyder det att de dokument som skapades i PROF-versionen nu också finns i underkonto Registrering i Skatteverket NULL-värde och SQL-databasen accepterar inte detta. Och när du laddar databasen till SQL kommer följande fel att visas. Här kommer det faktiskt inte att finnas några NULL-värden i fildatabasen, men SQL kommer att ladda exakt sådana värden i sina tabeller. Därför måste vi här tvinga SQL-databasen att skapa dessa NULLs och sedan korrigera dem i fildatabasen Men jag kan inte berätta hur du gör detta.

Vad är ett index?

Den fysiska essensen av index i MS SQL Server 2005.

Unikt index

Vad ska man göra?

Läs också