Hai trovato un messaggio contenente le righe:
Provider Microsoft OLE DB per SQL Server: CREATE UNIQUE INDEX terminato perché è stata trovata una chiave duplicata per l'ID indice
o
Impossibile inserire la riga chiave duplicata I_nsert nell'oggetto
o
Un tentativo di inserire un valore non univoco in un indice univoco.
Opzioni soluzione:
1. In SQL Server Managment Studio, distruggiamo fisicamente l'indice non riuscito (nel mio caso, era un indice nella tabella dei totali del registro di contabilità). In 1C abbiamo diviso i documenti difettosi. Nella modalità di test e correzione, mettiamo i taccole sulla reindicizzazione delle tabelle + il conteggio dei totali. 1C ricrea l'indice senza errori. Eseguiamo documenti precedentemente falliti.
2.
1) Usando Management Studio 2005, ho generato uno script di creazione per creare un indice che era difettoso e l'ho salvato in un file.
2) Ucciso manualmente l'indice dello stipite dalla tabella _AccumRgTn19455
3) Lanciata una richiesta di visualizzazione
Codice SQL S_elect count (*), index_field
DA AccumRgTn19455
GROUP BY index_field
HAVING count (*)\u003e 1
Dopo che l'indice è stato ucciso, avevo 15 record duplicati visualizzati, anche se fino al passaggio 2 la query non ha restituito nulla.
4) Ho controllato tutti i record e ho pulito manualmente i duplicati. In effetti, ho ancora utilizzato l'elaborazione "Struttura dei report" per capire con cosa avevo a che fare. Si è scoperto che la tabella _AccumRgTn19455 memorizza il registro di accumulo "Output di produzione (contabilità fiscale)". Ho ancora cercato con query sql, identificato 15 documenti non univoci e dopo aver completato tutte le azioni ho verificato in 1C che questi documenti vengono elaborati normalmente, senza errori. Ovviamente, non dovresti semplicemente pulire i tavoli a caso: è importante capire cosa viene pulito e in cosa può trasformarsi.
5) Ho lanciato una richiesta per creare un indice salvato in un file.
6) Metti il \u200b\u200bdatabase in modalità utente singolo ed esegui dbcc checkdb - questa volta non è stato emesso un singolo errore.
7) Riportato il database in modalità utente singolo.
Questo è tutto ... il problema è stato sconfitto. Bene, nel 1C, ho lanciato "Testing and Correction", tutto è andato bene anche lì, ha smesso di imprecare contro un indice non univoco.
3. Se la non-unicità consiste in date con valori zero, quindi il problema viene risolto creando una base con un parametro offset di 2000.
1. Se il problema sta caricando il database, quindi:
1.1. Se si sta caricando (utilizzando il file dt) nel database MS SQL Server, durante la creazione del database, specificare un offset di data di 2000 prima di caricare.
Se il database è già stato creato con un offset di 0, crearne uno nuovo dal 2000.
1.2. Se è possibile lavorare con il database nella versione del file, eseguire Test e correzioni, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Ricerca di collegamenti non validi.
1.3. Se non è presente alcuna opzione di file, prova a scaricare da DT nella versione client-server con DB2 (che richiede meno unicità), quindi esegui Test e correzione, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Cerca collegamenti non validi.
1.4. Per localizzare il problema, è possibile determinare i dati dell'oggetto, il cui caricamento non è riuscito. Per fare ciò, è necessario abilitare la traccia nell'utilità Profiler all'avvio o abilitare la registrazione degli eventi DBMSSQL ed EXCP nel registro della tecnologia.
2. Se il problema di non univoci si verifica durante gli utenti:
2.1. Trova la query del problema usando il metodo della clausola 1.4.
2.1.2. A volte si verifica un errore durante l'esecuzione della query, ad esempio:
Questo errore si verifica perché nel modulo del registro di accumulo "Orario di lavoro dei dipendenti delle organizzazioni" nella procedura "Registra ricalcoli" la richiesta non contiene la parola di servizio "VARIE".
Codice 1C v 8.x cioè dovrebbe essere:
Richiesta \u003d Nuova richiesta (
"SCEGLI VARIE
| Basic.PhysFace,
. . . . .
Nelle ultime versioni di ZUP e SCP, non si verifica un errore, perché ci sono "VARIE".
2.2. Dopo aver trovato l'indice problematico dal paragrafo precedente, è necessario trovare un record non univoco.
2.2.1. Lo script "fish" per determinare record non univoci utilizzando SQL:
Codice SQL S_elect COUNT (*) Contatore,<перечисление всех полей соответствующего индекса> a partire dal<имя таблицы>
RAGGRUPPA PER<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Esempio. L'indice nell'errore si chiama "_Document140_VT1385_IntKeyIndNG".
L'elenco dei campi nella tabella:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Prima di eseguire la procedura seguente, fare di riserva Banca dati.
Esegui in MS SQL Server Query Analyzer:
Conteggio codice SQL S_elect (*), _Document140_IDRRef, _KeyField
da _Document140_VT1385
raggruppa per _Document140_IDRRef, _KeyField
avendo count (*)\u003e 1
Usalo per scoprire i valori delle colonne _Document140_IDRRef, _KeyField, record duplicati (id, chiave).
Su richiesta:
Codice SQL S_elect *
da _Document140_VT1385
o _Document140_IDRRef \u003d id2 e _KeyField \u003d key2 o ...
guarda i valori delle altre colonne di voci duplicate.
Se entrambi i record hanno valori significativi e questi valori sono diversi, correggere il valore di _KeyField su unique. Per fare ciò, determinare il valore massimo occupato di _KeyField (keymax):
Codice SQL S_elect max (_KeyField)
da _Document140_VT1385
dove _Document140_IDRRef \u003d id1
Sostituisci il valore _KeyField in una delle voci duplicate con quella corretta:
Aggiornamento codice SQL _Document140_VT1385
impostare _KeyField \u003d keymax + 1
Qui _LineNo1386 \u003d - condizione aggiuntiva, che consente di selezionare una delle due voci duplicate.
Se una (o entrambe) le voci ripetute hanno un valore ovviamente errato, è necessario eliminarle:
Eliminazione del codice SQL da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _LineNo1386 \u003d lineno1
Se le voci duplicate hanno gli stessi valori in tutte le colonne, una di esse deve essere lasciata sola:
Codice SQL S_elect distinto *
in # tmp1
da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1
Elimina da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1
Inserimento in _Document140_VT1385
S_elect # tmp1
Tabella D_rop # tmp1
La procedura descritta deve essere eseguita per ciascuna coppia di voci ripetute.
2.2.3. Secondo esempio:
Codice SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DA _Riferimento8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Un esempio della definizione di record non univoci utilizzando la query 1C: Enterprise:
Codice 1C v 8.x SELEZIONA Directory. Collegamento
DA Manuale. Manuale COME Manuale
Raggruppa per directory
QUANTITÀ DISPONIBILE (*)\u003e 1
L'errore si verifica se nel database alcuni oggetti, dettagli, sottoconto hanno un valore NULL, ma non possono avere tale valore. E un tale errore appare solo nei database SQL. Coloro. se tale database viene caricato in una base di file, questo errore non sarà già presente. Perché il file base ha le sue tabelle (4 in totale), mentre SQL ha le sue. E il database SQL reagisce in modo critico a tali valori nelle sue tabelle.
Questo problema non può essere risolto da alcun test (né esterno né interno) in nessuna opzione del database (SQL o file) e nemmeno dalla procedura _1sp_DBReindex in SQL Manager, che sembra supporre che ristrutturi le tabelle in SQL.
Analizziamo la soluzione del problema con l'esempio della transizione da PROF Accounting 3.0 a CORP. Dopo la transizione, il conto 68.01 appare una nuova registrazione del sottoconto nell'Agenzia delle Entrate. Quindi, nei database SQL, tutta la creazione nella versione PROF dei documenti che utilizzano questo account non verrà ridisegnata. L'errore mostrato sopra verrà abbandonato. Perché questo nuovo sottoconto di vecchi documenti, nelle transazioni, è scritto con un valore NULL (anche se dovrebbe essere un valore vuoto, beh, o in qualche modo l'autorità fiscale).
Per risolvere questo errore, è necessario rimuovere i valori NULL dove non dovrebbero essere. In questo caso, nei documenti in cui viene utilizzata la registrazione del subconto nell'autorità fiscale. Puoi farlo scrivendo un'elaborazione che sostituisce NULL con un valore Null (l'elaborazione pronta può essere scaricata da questo articolo). Per eseguire l'elaborazione, tk. un tentativo di modificare il valore di questo sottoconto nelle registrazioni dei documenti porta manualmente allo stesso errore.
L'elaborazione per la sostituzione di NULL in tutti i sottocontenti La registrazione nell'autorità fiscale può essere scaricata da questo articolo, di seguito.
MA, non funzionerà per sostituire NULL nel database SQL; lo stesso errore verrà generato durante l'elaborazione. Pertanto, è necessario eseguire questa operazione:
1. Scaricare una versione funzionante tradotta in CORP, database SQL in dt’shnik (nel configuratore di amministrazione - Scarica database - selezionare dove scaricare il database come file * .dt)
2. Scarica dt’shnik nel database dei file (in un database di file pulito, non necessario o pre-preparato, pulito, nel configuratore Amministrazione - Carica il database - seleziona il dt’shnik precedentemente scaricato)
3. Esegui l'elaborazione nel database dei file (non si verificheranno errori e tutti i NULL verranno sostituiti correttamente) (la procedura per eseguire l'elaborazione è descritta di seguito)
5. Ora, al contrario, scarica dt's dalla base file e caricalo nel database SQL. Ora, durante l'elaborazione dei documenti elaborati, non verrà emesso un errore.
L'elaborazione di questo articolo trova tutti i documenti per il periodo specificato, per i quali la registrazione del subcontatto nell'autorità fiscale (che appare nella versione CORP) appare nelle registrazioni, che ha un valore NULL. E sostituisce questo valore con null.
Nell'elaborazione è necessario indicare il periodo per il quale è necessario elaborare i documenti (è possibile per l'intero periodo in cui la contabilità è condotta nel database) e fare clic su "Compila la parte tabulare". Successivamente, è possibile verificare con daws quali documenti elaborare (è possibile selezionare tutto) e fare clic sul pulsante "Elabora".
Di conseguenza, se qualcuno ha lo stesso errore, ma NON dopo il passaggio a CORP, ma, ad esempio, dopo lo scambio, il download di alcuni dati, l'esecuzione di un processo, ecc. È necessario identificare dove è stato assegnato il valore NULL in un particolare documento / directory e in modo simile per rimuovere questo NULL, ma mediante la sua elaborazione, ma nell'ordine sopra descritto. Ricorda che NULL può essere come nelle pubblicazioni di documenti, incl. non solo la contabilità, ma da qualche parte nella forma di un documento / directory, in alcuni requisiti, ma in questo caso probabilmente non si aprirà nemmeno.
Inoltre, se si è verificato questo errore durante la conservazione di un documento dopo aver trasferito il database di file di BUG CORP su SQL (e il database era originariamente PROF), significa che i documenti creati nella versione PROF ora si trovano anche nella registrazione dell'account secondario nell'autorità fiscale Valore NULL e la base SQL non accetta questo. E quando si carica il database in SQL, verrà visualizzato un errore del genere. Qui, infatti, non ci saranno valori NULL nel database dei file, ma SQL caricherà proprio tali valori nelle sue tabelle. Pertanto, è necessario forzare base SQL crea questi NULL e poi correggili nel database dei file. Ma non ti dirò come farlo.
Hai trovato un messaggio contenente le righe:
Provider Microsoft OLE DB per SQL Server: CREATE UNIQUE INDEX terminato perché è stata trovata una chiave duplicata per l'ID indice
o
Impossibile inserire la riga chiave duplicata I_nsert nell'oggetto
o
Un tentativo di inserire un valore non univoco in un indice univoco.
Opzioni soluzione:
1. In SQL Server Managment Studio, distruggiamo fisicamente l'indice non riuscito (nel mio caso, era un indice nella tabella dei totali del registro di contabilità). In 1C abbiamo diviso i documenti difettosi. Nella modalità di test e correzione, mettiamo i taccole sulla reindicizzazione delle tabelle + il conteggio dei totali. 1C ricrea l'indice senza errori. Eseguiamo documenti precedentemente falliti.
2.
1) Usando Management Studio 2005, ho generato uno script di creazione per creare un indice che era difettoso e l'ho salvato in un file.
2) Ucciso manualmente l'indice dello stipite dalla tabella _AccumRgTn19455
3) Lanciata una richiesta di visualizzazione
Codice SQL S_elect count (*), index_field
FR OM AccumRgTn19455
GROUP BY index_field
HAVING count (*)\u003e 1
Dopo che l'indice è stato ucciso, avevo 15 record duplicati visualizzati, anche se fino al passaggio 2 la query non ha restituito nulla.
4) Ho controllato tutti i record e ho pulito manualmente i duplicati. In effetti, ho ancora utilizzato l'elaborazione "Struttura dei report" per capire con cosa avevo a che fare. Si è scoperto che la tabella _AccumRgTn19455 memorizza il registro di accumulo "Output di produzione (contabilità fiscale)". Ho ancora cercato con query sql, identificato 15 documenti non univoci e dopo aver completato tutte le azioni ho verificato in 1C che questi documenti vengono elaborati normalmente, senza errori. Ovviamente, non dovresti semplicemente pulire i tavoli a caso: è importante capire cosa viene pulito e in cosa può trasformarsi.
5) Ho lanciato una richiesta per creare un indice salvato in un file.
6) Metti il \u200b\u200bdatabase in modalità utente singolo ed esegui dbcc checkdb - questa volta non è stato emesso un singolo errore.
7) Riportato il database in modalità utente singolo.
Questo è tutto ... il problema è stato sconfitto. Bene, nel 1C, ho lanciato "Testing and Correction", tutto è andato bene anche lì, ha smesso di imprecare contro un indice non univoco.
3. Se la non-unicità consiste in date con valori zero, quindi il problema viene risolto creando una base con un parametro offset di 2000.
1. Se il problema sta caricando il database, quindi:
1.1. Se si sta caricando (utilizzando il file dt) nel database MS SQL Server, durante la creazione del database, specificare un offset di data di 2000 prima di caricare.
Se il database è già stato creato con un offset di 0, crearne uno nuovo dal 2000.
1.2. Se è possibile lavorare con il database nella versione del file, eseguire Test e correzioni, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Ricerca di collegamenti non validi.
1.3. Se non è presente alcuna opzione di file, prova a scaricare da DT nella versione client-server con DB2 (che richiede meno unicità), quindi esegui Test e correzione, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Cerca collegamenti non validi.
1.4. Per localizzare il problema, è possibile determinare i dati dell'oggetto, il cui caricamento non è riuscito. Per fare ciò, è necessario abilitare la traccia nell'utilità Profiler all'avvio o abilitare la registrazione degli eventi DBMSSQL ed EXCP nel registro della tecnologia.
2. Se il problema di non univoci si verifica durante gli utenti:
2.1. Trova la query del problema usando il metodo della clausola 1.4.
2.1.2. A volte si verifica un errore durante l'esecuzione della query, ad esempio:
Questo errore si verifica perché nel modulo del registro di accumulazione "Orario di lavoro dei dipendenti delle organizzazioni" nella procedura "Registra ricalcoli" la richiesta non contiene la parola di servizio "VARIE".
Codice 1C v 8.x cioè dovrebbe essere:
Richiesta \u003d Nuova richiesta (
"SCEGLI VARIE
| Basic.PhysFace,
. . . . .
Nelle ultime versioni di ZUP e SCP, non si verifica un errore, perché ci sono "VARIE".
2.2. Dopo aver trovato l'indice problematico dal paragrafo precedente, è necessario trovare un record non univoco.
2.2.1. Lo script "fish" per determinare record non univoci utilizzando SQL:
Codice SQL S_elect COUNT (*) Contatore,<перечисление всех полей соответствующего индекса> a partire dal<имя таблицы>
RAGGRUPPA PER<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Esempio. L'indice nell'errore si chiama "_Document140_VT1385_IntKeyIndNG".
L'elenco dei campi nella tabella:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Prima di eseguire la procedura seguente, eseguire il backup del database.
Esegui in MS SQL Server Query Analyzer:
Conteggio codice SQL S_elect (*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
raggruppa per _Document140_IDRRef, _KeyField
avendo count (*)\u003e 1
Usalo per scoprire i valori delle colonne _Document140_IDRRef, _KeyField, record duplicati (id, chiave).
Su richiesta:
Codice SQL S_elect *
fr om _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1 o _Document140_IDRRef \u003d id2 e _KeyField \u003d key2 o ...
guarda i valori delle altre colonne di voci duplicate.
Se entrambi i record hanno valori significativi e questi valori sono diversi, correggere il valore di _KeyField su unique. Per fare ciò, determinare il valore massimo occupato di _KeyField (keymax):
Codice SQL S_elect max (_KeyField)
fr om _Document140_VT1385
dove _Document140_IDRRef \u003d id1
Sostituisci il valore _KeyField in una delle voci duplicate con quella corretta:
Aggiornamento codice SQL ha mangiato _Document140_VT1385
impostare _KeyField \u003d keymax + 1
Qui _LineNo1386 \u003d è una condizione aggiuntiva che ti consente di selezionare una delle due voci duplicate.
Se una (o entrambe) le voci ripetute hanno un valore ovviamente errato, è necessario eliminarle:
Eliminazione del codice SQL da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _LineNo1386 \u003d lineno1
Se le voci duplicate hanno gli stessi valori in tutte le colonne, una di esse deve essere lasciata sola:
Codice SQL S_elect distinto *
in # tmp1
da _Document140_VT1385
Elimina da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1
Inserimento in _Document140_VT1385
S_elect # tmp1
Tabella D_rop # tmp1
La procedura descritta deve essere eseguita per ciascuna coppia di voci ripetute.
2.2.3. Secondo esempio:
Codice SQL S_elect COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DA _Riferimento8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Un esempio della definizione di record non univoci utilizzando la query 1C: Enterprise:
Codice 1C v 8.x SELEZIONA Directory. Collegamento
DA Manuale. Manuale COME Manuale
Raggruppa per directory
QUANTITÀ DISPONIBILE (*)\u003e 1
Informazioni tratte dal sito
Questo articolo descriverà cosa fare se, quando si lavora con 1C: Enterprise 8.1, viene visualizzato un messaggio contenente le righe:
Impossibile inserire la riga della chiave duplicata nell'oggetto
Un tentativo di inserire un valore non univoco in un indice univoco.
Cos'è un indice?
Gli indici sono una struttura che consente un accesso più rapido alle righe della tabella in base ai valori di una o più delle sue colonne.
L'indice contiene chiavi create da una o più colonne della tabella o vista e puntatori che sono mappati nella posizione di archiviazione per i dati specificati.
Gli indici riducono la quantità di dati che devono essere letti per restituire il set di risultati.
Sebbene l'indice sia associato a una colonna (o colonne) specifica della tabella, è comunque un oggetto di database indipendente.
Indici di tabelle nel database 1C: Enterprise vengono creati implicitamente durante la creazione di oggetti di configurazione, nonché con varie impostazioni degli oggetti di configurazione.
La natura fisica degli indici in MS SQL Server 2005.
Dati archiviati fisicamente su pagine 8K. Immediatamente dopo la creazione, mentre la tabella non ha indici, la tabella sembra un mucchio di dati. I record non hanno un ordine di archiviazione specifico.
Quando si desidera accedere ai dati, verrà prodotto SQL Server scansione della tabella (scansione tabella). SQL Server esegue la scansione dell'intera tabella per trovare i record che stai cercando.
Da qui diventano chiari funzioni base indici:
- aumento della velocità di accesso ai dati,
- supporto per l'unicità dei dati.
Nonostante i vantaggi, gli indici presentano anche numerosi svantaggi. Il primo sono gli indici occupare spazio su disco aggiuntivo e dentro memoria ad accesso casuale. Ogni volta che si crea un indice, si salvano le chiavi in \u200b\u200bordine decrescente o crescente, che può avere una struttura a più livelli. E più grande / più lunga è la chiave, il taglia più grande indice. Il secondo svantaggio è le operazioni stanno rallentando inserimento, aggiornamento ed eliminazione di record.
MS SQL Server 2005 implementa diversi tipi di indici:
- indici non cluster;
- indici cluster (o cluster);
- indici unici
- indici abilitati alla colonna
- viste indicizzate
- testo intero
Indice unico
I valori univoci nella colonna indicizzata sono garantiti da indici univoci. Se esistono, il server non ti consentirà di inserire un nuovo o modificare il valore esistente in modo che, come risultato di questa operazione, nella colonna compaiano due valori identici.
L'indice univoco è una sorta di componente aggiuntivo e può essere implementato sia per gli indici cluster che per quelli non cluster. Un cluster univoco e molti indici univoci non cluster possono esistere in una tabella.
Gli indici unici dovrebbero essere determinati solo quando è veramente necessario. Per garantire l'integrità dei dati in una colonna, è possibile definire un vincolo di integrità UNIQUE o PRIMARY KEY, anziché ricorrere a indici univoci. Il loro utilizzo solo per garantire l'integrità dei dati è uno spreco ingiustificato di spazio nel database. Inoltre, il tempo della CPU viene impiegato per mantenerli.
1C: Enterprise 8.1 dalla versione 8.1 utilizza attivamente indici univoci del cluster. Ciò significa che durante la conversione da 8.0 o il passaggio da 8.1.7, è possibile ottenere un errore dell'indice non univoco.
Se la non-unicità si trova in date con valori zero, il problema viene risolto creando una base con un parametro offset di 2000.
Cosa fare?
1. Se il problema sta caricando il database, quindi:
1.1. Se si sta caricando (utilizzando il file dt) nel database MS SQL Server, durante la creazione del database, specificare un offset di data di 2000 prima di caricare.
Se il database è già stato creato con un offset di 0, crearne uno nuovo dal 2000.
1.2. Se è possibile lavorare con il database nella versione del file, eseguire Test e correzioni, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Ricerca di collegamenti non validi.
1.3. Se non è presente alcuna opzione di file, prova a scaricare da DT nella versione client-server con DB2 (che richiede meno unicità), quindi esegui Test e correzione, nonché Configurazione - Verifica della configurazione - Verifica dell'integrità logica della configurazione + Cerca collegamenti non validi.
1.4. Per localizzare il problema, è possibile determinare i dati dell'oggetto, il cui caricamento non è riuscito. Per fare ciò, è necessario abilitare la traccia nell'utility Profiler all'avvio o abilitare la registrazione nel registro eventi della tecnologia DBMSSQL ed EXCP.
1.5. Se è disponibile un nodo (piani di scambio), quindi eseguire lo scambio. Puoi anche eseguire facoltativamente il paragrafo 2.3.5 prima dello scambio
2. Se il problema di non univoci si verifica durante gli utenti:
2.1. Trova la query del problema usando il metodo della clausola 1.4.
2.1.2. A volte si verifica un errore durante l'esecuzione della query, ad esempio:
Questo errore si verifica perché nel modulo del registro di accumulazione "Orario di lavoro dei dipendenti delle organizzazioni" nella procedura "Registra ricalcoli" la richiesta non contiene la parola di servizio "VARIE".
Coloro. dovrebbe essere:
Richiesta \u003d Nuova richiesta (
"SCEGLI VARIE
| Basic.PhysFace,
Nelle ultime versioni di ZUP e SCP, non si verifica un errore, perché ci sono "VARIE".
2.2. Dopo aver trovato l'indice problematico dal paragrafo precedente, è necessario trovare un record non univoco.
2.2.1. Lo script "fish" per determinare record non univoci utilizzando SQL:
SELEZIONA CONTEGGIO (*) Contatore,<перечисление всех полей соответствующего индекса> a partire dal<имя таблицы>
RAGGRUPPA PER<перечисление всех полей соответствующего индекса>
HAVING Counter\u003e 1
2.2.2 Esempio. L'indice nell'errore si chiama "_Document140_VT1385_IntKeyIndNG".
L'elenco dei campi nella tabella:
Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RR93, _Fld1393_RR93
Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261
Prima di eseguire la procedura seguente, eseguire il backup del database.
Esegui in MS SQL Server Query Analyzer:
seleziona count (*), _Document140_IDRRef, _KeyField
da _Document140_VT1385
raggruppa per _Document140_IDRRef, _KeyField
avendo count (*)\u003e 1
Usalo per scoprire i valori delle colonne _Document140_IDRRef, _KeyField, record duplicati (id, chiave).
Su richiesta:
selezionare *
da _Document140_VT1385
o _Document140_IDRRef \u003d id2 e _KeyField \u003d key2 o ...
guarda i valori delle altre colonne di voci duplicate.
Se entrambi i record hanno valori significativi e questi valori sono diversi, correggere il valore di _KeyField su unique. Per fare ciò, determinare il valore massimo occupato di _KeyField (keymax):
seleziona max (_KeyField)
da _Document140_VT1385
dove _Document140_IDRRef \u003d id1
Sostituisci il valore _KeyField in una delle voci duplicate con quella corretta:
aggiorna _Document140_VT1385
impostare _KeyField \u003d keymax + 1
Qui _LineNo1386 \u003d è una condizione aggiuntiva che ti consente di selezionare una delle due voci duplicate.
Se una (o entrambe) le voci ripetute hanno un valore ovviamente errato, è necessario eliminarle:
dove _Document140_IDRRef \u003d id1 e _LineNo1386 \u003d lineno1
Se le voci duplicate hanno gli stessi valori in tutte le colonne, una di esse deve essere lasciata sola:
seleziona distinto *
in # tmp1
da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1
eliminare da _Document140_VT1385
dove _Document140_IDRRef \u003d id1 e _KeyField \u003d key1
inserire in _Document140_VT1385
seleziona # tmp1
drop table # tmp1
La procedura descritta deve essere eseguita per ciascuna coppia di voci ripetute.
2.2.3. Secondo esempio:
SELEZIONA COUNT (*) AS Expr2, _IDRRef AS Expr1, _Description
DA _Riferimento8_
GROUP BY _IDRRef, _Description
HAVING (COUNT (*)\u003e 1)
2.3.4 Un esempio della definizione di record non univoci utilizzando la query 1C: Enterprise:
o per la contabilità
SCEGLIERE
Periodo di subquery
Sottoquery: Registrar,
<измерения>,
IMPORTO (Numero query. Numero di record) AS Numero di record
DI
(SCEGLIERE
Autoportante Periodo AS Periodo,
Autoportante Registrar AS Registrar,
<измерения>,
1 AS Numero di record
DI
Registro dei conti Autoportante AS Autoportante) Sottosquadra AS
RAGGRUPPA PER
Periodo di subquery
Sottoquery: Registrar,
<измерения>
avere
IMPORTO (Sottoquery.Number di voci)\u003e 1
2.3.5 Per rendere l'indice subd non univoco. Script dell'indice utilizzando Management Studio.
2.3.6 Un caso speciale nello scambio nel RDB. L'errore ricade sulle tabelle "ausiliarie" relative al calcolo di totali o analisi. Per esempio:
Errore durante la chiamata al metodo di contesto (Scrittura): tentativo di inserire un valore non univoco in un indice univoco:
Provider Microsoft OLE DB per SQL Server: impossibile inserire una riga di chiave duplicata nell'oggetto "dbo._AccntRegED10319" con indice univoco "_Accnt10319_ByPeriod_TRNRN".
HRESULT \u003d 80040E2F, SQLSrvr: stato di errore \u003d 1, gravità \u003d E, nativo \u003d 2601, riga \u003d 1
In questo caso, disattivare l'uso dei totali prima di scaricare, scaricare il messaggio, abilitare l'uso dei totali e ripetere il conteggio.
