Você recebeu uma mensagem contendo as linhas:
Provedor Microsoft OLE DB para SQL Server: CREATE UNIQUE INDEX encerrado porque uma chave duplicada foi encontrada para o ID do índice
ou
Não é possível inserir linha de chave duplicada no objeto
ou
Foi feita uma tentativa de inserir um valor não exclusivo em um índice exclusivo.

Soluções:

1. No SQL Server Management Studio, destruímos fisicamente o índice defeituoso (no meu caso, era um índice na tabela de totais do registro contábil). Em 1C distribuiremos os documentos defeituosos. No modo de teste e correção, marque as caixas de reindexação da tabela + recálculo dos totais. 1C recria o índice sem erros. Realizamos documentos anteriormente falhados.

2. 1) Usando o Management Studio 2005, gerei um script de criação para criar um índice, que apresentava bugs, e salvei-o em um arquivo.
2) Eliminou manualmente o índice do batente da tabela _AccumRgTn19455
3) Lançou uma solicitação como
Código SQL S_elect contagem(*), index_fields
FR OM AccumRgTn19455
GRUPO POR campo_índice
TENDO contagem(*)>1
Depois que o índice foi eliminado, 15 registros duplicados foram exibidos, embora antes da etapa 2 a consulta não retornasse nada.
4) Examinei todas as entradas e limpei manualmente as duplicatas. Na verdade, também usei o processamento de “Estrutura do Relatório” para entender com o que estava lidando. Descobriu-se que a tabela _AccumRgTn19455 armazena o registro de acumulação “Saída de produtos (contabilidade fiscal)”. Também mexi nas consultas sql, identifiquei 15 documentos não exclusivos e, depois de concluídas todas as ações, verifiquei em 1C se esses documentos foram processados ​​​​normalmente, sem erros. Claro, você não deve apenas limpar mesas aleatoriamente: é importante entender o que está sendo limpo e como isso pode acontecer.
5) Lançou uma solicitação para criar um índice, que foi salvo em um arquivo.
6) Mudou o banco de dados para o modo de usuário único e iniciou o dbcc checkdb - desta vez nenhum erro foi gerado.
7) Mudou a base de volta para o modo de usuário único.
É isso... o problema está superado. Bom, lá em 1C lancei “Teste e Correção”, deu tudo certo lá também, parei de reclamar do índice não único.

3. Se a não exclusividade estiver em datas com valores zero, então o problema é resolvido criando um banco de dados com parâmetro de deslocamento igual a 2.000.

1. Se o problema for carregar o banco de dados, então:
1.1. Se você estiver carregando (usando um arquivo dt) em um banco de dados MS SQL Server, ao criar o banco de dados, antes de carregar, especifique o deslocamento de data - 2000.
Se o banco de dados já foi criado com deslocamento 0, crie um novo com 2.000.

1.2. Caso seja possível trabalhar com o banco de dados na versão arquivo, então realizar Testes e Correções, bem como Configuração - Verificação da configuração - Verificação da integridade lógica da configuração + Busca de links incorretos.

1.3. Se não versão do arquivo, tente carregar do DT em uma versão cliente-servidor com DB2 (que exige menos exclusividade) e, em seguida, execute testes e correções, bem como Configuração - Verificação de configuração - Verificação da integridade lógica da configuração + Localização de links incorretos.

1.4. Para localizar o problema, você pode determinar os dados do objeto cujo carregamento falhou. Para fazer isso, você precisa ativar o rastreamento no utilitário Profiler durante a inicialização ou ativar a gravação no log de eventos do processo DBMSSQL e EXCP.

2. Se o problema de não exclusividade ocorrer enquanto os usuários estiverem trabalhando:

2.1. Encontre a solicitação problemática usando o método do parágrafo 1.4.

2.1.2. Às vezes ocorre um erro durante a execução de consultas, por exemplo:

Este erro ocorre devido ao fato de no módulo de registro de acumulação " Horas de trabalho funcionários de organizações" no procedimento "Recálculos Cadastrais", a solicitação não contém a palavra de serviço "DIFERENTE".
Código 1C v 8.x Ou seja deveria ser:
Solicitação = Nova Solicitação(
"SELECIONE VÁRIOS
| Básico.Individual,
. . . . .
Nas últimas versões do ZUP e UPP o erro não ocorre, pois diz "DIFERENTE".

2.2. Depois de encontrar o índice problemático do parágrafo anterior, você precisa encontrar um registro não exclusivo.
2.2.1. Script "Fish" para identificar registros não exclusivos usando SQL:
Código SQL S_elect COUNT(*) Contador,<перечисление всех полей соответствующего индекса>de<имя таблицы>
Agrupar por<перечисление всех полей соответствующего индекса>
TENDO Contador > 1

2.2.2 Exemplo. O índice no erro é denominado "_Document140_VT1385_IntKeyIndNG".
Lista de campos da tabela:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_ RRRef, _Fld1394,_F ld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Antes de realizar o procedimento abaixo, faça cópia de segurança bancos de dados.
Execute no analisador de consultas do MS SQL Server:
Contagem S_elect do código SQL (*), _Document140_IDRRef, _KeyField
de _Document140_VT1385
agrupar por _Document140_IDRRef, _KeyField
tendo contagem(*) > 1
Use-o para descobrir os valores das colunas _Document140_IDRRef, _KeyField, registros duplicados (id, chave).

Usando a solicitação:
Código SQL S_elect *
de _Document140_VT1385
onde _Document140_IDRRef = id1 e _KeyField = key1 ou _Document140_IDRRef = id2 e _KeyField = key2 ou ...
observe os valores das outras colunas das entradas duplicadas.
Se ambas as entradas tiverem valores significativos e os valores forem diferentes, altere o valor _KeyField para ser exclusivo. Para fazer isso, determine o valor máximo ocupado de _KeyField (keymax):
Código SQL S_elect max(_KeyField)
de _Document140_VT1385
onde está _Document140_IDRRef = id1
Substitua o valor _KeyField em uma das entradas duplicadas pelo correto:
Atualização do código SQL _Document140_VT1385
definir _KeyField = keymax + 1

Aqui _LineNo1386 = é uma condição adicional que permite selecionar um dos dois registros repetidos.

Se uma (ou ambas) das entradas duplicadas tiver um significado obviamente incorreto, ela deverá ser removida:
Exclusão de código SQL de _Document140_VT1385
onde estão _Document140_IDRRef = id1 e _LineNo1386 = lineno1
Se as entradas duplicadas tiverem os mesmos valores em todas as colunas, será necessário deixar uma delas:
Código SQL S_elect distinto *
em #tmp1
de _Documento140_VT1385

Excluir de _Document140_VT1385
onde estão _Document140_IDRRef = id1 e _KeyField = key1

Eu_insiro em _Document140_VT1385
S_elect #tmp1

Tabela D_rop #tmp1

O procedimento descrito deve ser realizado para cada par de registros duplicados.

2.2.3. Segundo exemplo:
Código SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Referência8_
GRUPO POR _IDRRef, _Descrição
TENDO (CONTAR(*) > 1)

2.3.4 Um exemplo de determinação de registros não exclusivos usando uma consulta 1C:Enterprise:
Código 1C v 8.x SELECIONE Directory.Link
DE Directory.Directory AS Diretório
GRUPO POR Diretório.Link
TENDO QUANTIDADE(*) > 1

Informações retiradas do site

Ocorre um erro se alguns objetos, detalhes, subcontos no banco de dados tiverem um valor NULL, mas não podem ter tal valor. E esse erro aparece apenas em bancos de dados SQL. Aqueles. Se você carregar esse banco de dados em um arquivo, esse erro não existirá mais. Porque O banco de dados de arquivos possui suas próprias tabelas (4 no total) e o SQL possui as suas próprias. E o banco de dados SQL reage criticamente a esses valores em suas tabelas.

Este problema não pode ser resolvido por nenhum teste (nem externo nem interno) em qualquer versão do banco de dados (SQL ou arquivo) e mesmo pelo procedimento _1sp_DBReindex no gerenciador SQL, que parece supostamente reestruturar tabelas em SQL.

Vejamos a solução do problema usando o exemplo da mudança do Accounting 3.0 PROF para o CORP. Após a transição, a conta 68.01 passa a ter uma nova subconta, Registo na Autoridade Tributária. E então, nos bancos de dados SQL, todos os documentos criados na versão PRO que utilizem esta conta não serão transferidos. O erro mostrado acima aparecerá. Porque Esta nova subconta para documentos antigos, em lançamentos, será escrita com o valor NULO (embora deva haver um valor Vazio, ou de alguma forma o Fisco).

Para corrigir esse erro, você precisa remover os valores NULL onde eles não deveriam estar. Neste caso, em documentos onde seja utilizado o subconto Registo na Autoridade Tributária. Isso pode ser feito escrevendo um processamento que substituirá NULL por um valor Vazio (o processamento pronto pode ser baixado deste artigo). Faça isso processando, porque Uma tentativa de alterar manualmente o valor desta subconta nos lançamentos de documentos resulta no mesmo erro.

O processamento para substituição de NULL em todos os subcontactos do Registo na Autoridade Tributária pode ser descarregado neste artigo, abaixo.

MAS não funcionará substituir NULL no banco de dados SQL; durante o processamento será gerado o mesmo erro. Portanto, você precisa fazer isso:

1. Carregue a versão já funcional do banco de dados SQL, traduzida para CORP, no arquivo dt (no configurador Administração – Carregar banco de dados – selecione onde carregar o banco de dados como um arquivo *.dt)

2. Faça upload do dt’shnik para o banco de dados de arquivos (em um arquivo desnecessário ou pré-preparado, limpo e banco de dados de arquivos, no configurador Administração – Carregar banco de dados – selecione o arquivo dt baixado anteriormente)

3. Execute o processamento no banco de dados de arquivos (não haverá erros lá e todos os NULLs serão substituídos corretamente) (como realizar o processamento é descrito abaixo)

5. Agora, ao contrário, descarregue o arquivo dt do banco de dados de arquivos e carregue-o no banco de dados SQL. Agora, ao lançar documentos processados, não ocorrerão erros.

O processamento deste artigo encontra todos os documentos do período determinado em que os lançamentos incluem Registo de subcontratação na Autoridade Tributária (que aparece na versão CORP), que tem o valor NULO. E substitui esse valor por um valor Vazio.

No processamento, você deve indicar o período para o qual deseja processar os documentos (é possível para todo o período em que os registros são mantidos no banco de dados) e clicar em “Preencher parte tabular" Em seguida, você pode marcar as caixas para marcar quais documentos processar (você pode selecionar todos) e clicar no botão “Executar processamento”.

Assim, se alguém tiver o mesmo erro, mas NÃO depois de mudar para CORP, mas por exemplo depois de trocar, carregar alguns dados, realizar algum processamento, etc. Depois você precisa identificar onde o valor NULL foi atribuído em um documento/diretório específico e remover esse NULL de forma semelhante, mas com processamento próprio, mas na ordem descrita acima. Lembre-se que NULL pode ser, como nos lançamentos de documentos, incl. não só contábeis, mas também em algum lugar na forma de documento/livro de referência, com alguns detalhes, mas neste caso provavelmente nem abrirá.

Além disso, se este erro apareceu para você ao postar um documento, depois de transferir o banco de dados do arquivo Bukh KORP para SQL (e o banco de dados já foi originalmente PROF), significa que os documentos que foram criados na versão PROF agora também estão no Registo de subconta na Autoridade Tributária com valor NULL e a base de dados SQL não aceita isto. E ao carregar o banco de dados no SQL, aparecerá o seguinte erro. Aqui, de fato, não haverá valores NULL no banco de dados de arquivos, mas o SQL carregará exatamente esses valores em suas tabelas. Portanto, aqui precisamos forçar o banco de dados SQL a criar esses NULLs e depois corrigi-los no banco de dados de arquivos, mas não posso dizer como fazer isso.

Este artigo descreverá o que fazer se, ao trabalhar com 1C:Enterprise 8.1, você encontrar uma mensagem contendo as linhas:

Não é possível inserir linha de chave duplicada no objeto

Foi feita uma tentativa de inserir um valor não exclusivo em um índice exclusivo.

O que é um índice?

Os índices são uma estrutura que permite acesso rápido às linhas de uma tabela com base nos valores de uma ou mais de suas colunas.
Um índice contém chaves, construídas a partir de uma ou mais colunas de uma tabela ou visualização, e ponteiros que mapeiam para onde os dados especificados estão armazenados.
Os índices reduzem a quantidade de dados que devem ser lidos para retornar um conjunto de resultados.

Embora um índice esteja associado a uma coluna (ou colunas) específica de uma tabela, ele ainda é um objeto de banco de dados separado.

Os índices de tabelas no banco de dados 1C:Enterprise são criados implicitamente ao criar objetos de configuração, bem como durante certas configurações de objetos de configuração.

A essência física dos índices no MS SQL Server 2005.

Fisicamente os dados são armazenados em páginas de 8 KB. Imediatamente após a criação, embora a tabela não possua índices, a tabela parece uma pilha de dados. Os registros não possuem ordem específica de armazenamento.
Quando você quiser acessar dados, o SQL Server produzirá varredura de mesa(varredura de mesa). O SQL Server verifica toda a tabela para encontrar os registros que procura.
A partir daqui as funções básicas dos índices ficam claras:
— aumentar a velocidade de acesso aos dados,
— suporte para exclusividade de dados.

Apesar de suas vantagens, os índices também apresentam uma série de desvantagens. O primeiro são os índices ocupar espaço adicional em disco e em BATER. Cada vez que você cria um índice, você armazena as chaves em ordem decrescente ou crescente, que pode ter uma estrutura de vários níveis. E quanto maior/mais longa a chave, mais tamanho maioríndice. A segunda desvantagem é as operações estão desacelerando inserção, atualização e exclusão de registros.
No ambiente MS SQL Server 2005, vários tipos de índices são implementados:

• índices não clusterizados;
• índices agrupados (ou clusterizados);
• índices únicos;
• índices com colunas incluídas
• visualizações indexadas
• texto completo

Índice único

A exclusividade dos valores na coluna indexada é garantida por índices únicos. Se estiverem presentes, o servidor não permitirá inserir um novo ou alterar valor existente para que como resultado desta operação dois valores idênticos apareçam na coluna.
Um índice exclusivo é um tipo de complemento e pode ser implementado para índices clusterizados e não clusterizados. Uma tabela pode ter um índice clusterizado exclusivo e muitos índices não clusterizados exclusivos.
Índices exclusivos só devem ser definidos quando realmente necessários. Para garantir a integridade dos dados em uma coluna, você pode definir uma restrição de integridade UNIQUE ou PRIMARY KEY em vez de recorrer a índices exclusivos. Usá-los apenas para garantir a integridade dos dados é um desperdício de espaço de banco de dados. Além disso, o tempo da CPU também é gasto em sua manutenção.

1C:Enterprise 8.1, a partir da versão 8.1, usa ativamente índices exclusivos em cluster. Isso significa que ao converter da versão 8.0 ou migrar da versão 8.1.7 você poderá receber um erro de índice não exclusivo.

Se a não exclusividade estiver em datas com valores zero, o problema é resolvido criando um banco de dados com parâmetro de deslocamento igual a 2.000.

O que fazer?

1. Se o problema for carregar o banco de dados, então:

1.1. Se você estiver carregando (usando um arquivo dt) em um banco de dados MS SQL Server, ao criar o banco de dados antes de carregar, especifique o deslocamento de data - 2000.

Se o banco de dados já foi criado com deslocamento 0, crie um novo com 2.000.

1.2. Caso seja possível trabalhar com o banco de dados na versão arquivo, então realizar Testes e Correções, bem como Configuração - Verificação da configuração - Verificação da integridade lógica da configuração + Busca de links incorretos.

1.3. Se não houver versão do arquivo, tente carregar do DT para uma versão cliente-servidor com DB2 (que exige menos exclusividade) e, em seguida, execute Teste e Correção, bem como Configuração - Verifique a Configuração - Verifique a Integridade Lógica da Configuração + Procure referências inválidas.

1.4. Para localizar o problema, você pode determinar os dados do objeto cujo carregamento falhou. Para fazer isso, você precisa habilitar o rastreamento no utilitário Profiler durante a inicialização ou habilitar a gravação no log de eventos tecnológicos DBMSSQL e EXCP.

1.5. Se o nó (planos de troca) estiver disponível, execute a troca. Você também pode completar o parágrafo 2.3.5 antes de trocar

2. Se o problema de não exclusividade ocorrer enquanto os usuários estiverem trabalhando:

2.1. Encontre a solicitação problemática usando o método do parágrafo 1.4.

2.1.2. Às vezes ocorre um erro durante a execução de consultas, por exemplo:

Este erro ocorre devido ao fato de no módulo de registro de acumulação “Tempo de trabalho dos funcionários das organizações” no procedimento “Cadastro de recálculos” a palavra de serviço “DIFERENTE” não constar na solicitação.

Aqueles. deveria ser:

Solicitação = Nova Solicitação(
"SELECIONE VÁRIOS
| Básico.Individual,

Nas últimas versões do ZUP e UPP o erro não ocorre, pois diz “DIFERENTE”.

2.2. Depois de encontrar o índice problemático do parágrafo anterior, você precisa encontrar um registro não exclusivo.

2.2.1. Script "Fish" para identificar registros não exclusivos usando SQL:
SELECIONE CONTAGEM(*) Contador,<перечисление всех полей соответствующего индекса>de<имя таблицы>
Agrupar por<перечисление всех полей соответствующего индекса>
TENDO Contador > 1

2.2.2 Exemplo. O índice no erro é denominado "_Document140_VT1385_IntKeyIndNG".

Lista de campos da tabela:

Documento140_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, _Fld2226 1_RRRef

Antes de realizar o procedimento abaixo, faça backup do seu banco de dados.
Execute no analisador de consultas do MS SQL Server:

selecione contagem (*), _Document140_IDRRef, _KeyField
de _Documento140_VT1385
agrupar por _Document140_IDRRef, _KeyField
tendo contagem(*) > 1

Use-o para descobrir os valores das colunas _Document140_IDRRef, _KeyField, registros duplicados (id, chave).

Usando a solicitação:

selecione *
de _Documento140_VT1385
ou _Document140_IDRRef = id2 e _KeyField = key2 ou…

observe os valores das outras colunas das entradas duplicadas.

Se ambas as entradas tiverem valores significativos e os valores forem diferentes, altere o valor _KeyField para ser exclusivo. Para fazer isso, determine o valor máximo ocupado de _KeyField (keymax):

selecione max(_KeyField)
de _Documento140_VT1385
onde _Document140_IDRRef = id1

Substitua o valor _KeyField em uma das entradas duplicadas pelo correto:

atualização_Documento140_VT1385
definir _KeyField = keymax + 1

Aqui _LineNo1386 = é uma condição adicional que permite selecionar um dos dois registros repetidos.

Se uma (ou ambas) das entradas duplicadas tiver um significado obviamente incorreto, ela deverá ser removida:

onde _Document140_IDRRef = id1 e _LineNo1386 = lineno1

Se as entradas duplicadas tiverem os mesmos valores em todas as colunas, você precisará deixar uma delas:

selecione distinto *
em #tmp1
de _Documento140_VT1385
onde _Document140_IDRRef = id1 e _KeyField = key1

excluir de _Document140_VT1385
onde _Document140_IDRRef = id1 e _KeyField = key1

inserir em _Document140_VT1385
selecione #tmp1

eliminar tabela #tmp1

O procedimento descrito deve ser realizado para cada par de registros duplicados.

2.2.3. Segundo exemplo:

SELECIONE CONTAGEM(*) AS Expr2, _IDRRef AS Expr1, _Descrição
DE _Referência8_
GRUPO POR _IDRRef, _Descrição
TENDO (CONTAR(*) > 1)

2.3.4 Um exemplo de determinação de registros não exclusivos usando uma consulta 1C:Enterprise:

ou para contabilidade

ESCOLHER
Subconsulta.Período,
Subconsulta.Recorder,
<измерения>,
SOMA(Subconsulta.Número de Registros) AS Número de Registros
DE
(ESCOLHER
Autossustentável. Período AS Período,
Autossustentável.Registrar AS Registrador,
<измерения>,
1 AS Número de registros
DE
Registro Contábil. Autossustentável AS Autossuficiente) AS Subconsulta.

Agrupar por
Subconsulta.Período,
Subconsulta.Recorder,
<измерения>

TENDO
SOMA(Subconsulta.Número de Registros) > 1

2.3.5 Torne o índice subd não exclusivo. Faça o script do índice usando o Management Studio.

2.3.6 Um caso especial de troca no RDB. O erro ocorre em tabelas “auxiliares” associadas ao cálculo de totais ou análises. Por exemplo:

Erro ao chamar o método de contexto (Write): Tentativa de inserir um valor não exclusivo em um índice exclusivo:
Provedor Microsoft OLE DB para SQL Server: não é possível inserir linha de chave duplicada no objeto 'dbo._AccntRegED10319' com índice exclusivo '_Accnt10319_ByPeriod_TRNRN'.
HRESULT=80040E2F, SQLSrvr: Estado de erro=1, Gravidade=E, nativo=2601, linha=1

Neste caso, antes de carregar, desative o uso de totais, carregue a mensagem, habilite o uso de totais e recalcule.

Você recebeu uma mensagem contendo as linhas:
Provedor Microsoft OLE DB para SQL Server: CREATE UNIQUE INDEX encerrado porque uma chave duplicada foi encontrada para o ID do índice
ou
Não é possível inserir linha de chave duplicada no objeto
ou
Foi feita uma tentativa de inserir um valor não exclusivo em um índice exclusivo.

Soluções:

1. No SQL Server Management Studio, destruímos fisicamente o índice defeituoso (no meu caso, era um índice na tabela de totais do registro contábil). Em 1C distribuiremos os documentos defeituosos. No modo de teste e correção, marque as caixas de reindexação da tabela + recálculo dos totais. 1C recria o índice sem erros. Realizamos documentos anteriormente falhados.

2. 1) Usando o Management Studio 2005, gerei um script de criação para criar um índice, que apresentava bugs, e salvei-o em um arquivo.
2) Eliminou manualmente o índice do batente da tabela _AccumRgTn19455
3) Lançou uma solicitação como
Código SQL S_elect contagem(*), index_fields
DE AccumRgTn19455
GRUPO POR campo_índice
TENDO contagem(*)>1
Depois que o índice foi eliminado, 15 registros duplicados foram exibidos, embora antes da etapa 2 a consulta não retornasse nada.
4) Examinei todas as entradas e limpei manualmente as duplicatas. Na verdade, também usei o processamento de “Estrutura do Relatório” para entender com o que estava lidando. Descobriu-se que a tabela _AccumRgTn19455 armazena o registro de acumulação “Saída de produtos (contabilidade fiscal)”. Também mexi nas consultas sql, identifiquei 15 documentos não exclusivos e, depois de concluídas todas as ações, verifiquei em 1C se esses documentos foram processados ​​​​normalmente, sem erros. Claro, você não deve apenas limpar mesas aleatoriamente: é importante entender o que está sendo limpo e como isso pode acontecer.
5) Lançou uma solicitação para criar um índice, que foi salvo em um arquivo.
6) Mudou o banco de dados para o modo de usuário único e iniciou o dbcc checkdb - desta vez nenhum erro foi gerado.
7) Mudou a base de volta para o modo de usuário único.
É isso... o problema está superado. Bom, lá em 1C lancei “Teste e Correção”, deu tudo certo lá também, parei de reclamar do índice não único.

3. Se a não exclusividade estiver em datas com valores zero, então o problema é resolvido criando um banco de dados com parâmetro de deslocamento igual a 2.000.

1. Se o problema for carregar o banco de dados, então:
1.1. Se você estiver carregando (usando um arquivo dt) em um banco de dados MS SQL Server, ao criar o banco de dados, antes de carregar, especifique o deslocamento de data - 2000.
Se o banco de dados já foi criado com deslocamento 0, crie um novo com 2.000.

1.2. Caso seja possível trabalhar com o banco de dados na versão arquivo, então realizar Testes e Correções, bem como Configuração - Verificação da configuração - Verificação da integridade lógica da configuração + Busca de links incorretos.

1.3. Se não houver versão do arquivo, tente carregar do DT para uma versão cliente-servidor com DB2 (que exige menos exclusividade) e, em seguida, execute Teste e Correção, bem como Configuração - Verifique a Configuração - Verifique a Integridade Lógica da Configuração + Procure referências inválidas.

1.4. Para localizar o problema, você pode determinar os dados do objeto cujo carregamento falhou. Para fazer isso, você precisa ativar o rastreamento no utilitário Profiler durante a inicialização ou ativar a gravação no log de eventos do processo DBMSSQL e EXCP.

2. Se o problema de não exclusividade ocorrer enquanto os usuários estiverem trabalhando:

2.1. Encontre a solicitação problemática usando o método do parágrafo 1.4.

2.1.2. Às vezes ocorre um erro durante a execução de consultas, por exemplo:

Este erro ocorre devido ao fato de no módulo de registro de acumulação “Tempo de trabalho dos funcionários das organizações” no procedimento “Cadastro de recálculos” a palavra de serviço “DIFERENTE” não constar na solicitação.
Código 1C v 8.x Ou seja deveria ser:
Solicitação = Nova Solicitação(
"SELECIONE VÁRIOS
| Básico.Individual,
. . . . .
Nas últimas versões do ZUP e UPP o erro não ocorre, pois diz "DIFERENTE".

2.2. Depois de encontrar o índice problemático do parágrafo anterior, você precisa encontrar um registro não exclusivo.
2.2.1. Script "Fish" para identificar registros não exclusivos usando SQL:
Código SQL S_elect COUNT(*) Contador,<перечисление всех полей соответствующего индекса>de<имя таблицы>
Agrupar por<перечисление всех полей соответствующего индекса>
TENDO Contador > 1

2.2.2 Exemplo. O índice no erro é denominado "_Document140_VT1385_IntKeyIndNG".
Lista de campos da tabela:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_ RRRef, _Fld1394,_F ld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261 _RTRef, _Fld22261_RRRef
Antes de realizar o procedimento abaixo, faça backup do seu banco de dados.
Execute no analisador de consultas do MS SQL Server:
Contagem S_elect do código SQL (*), _Document140_IDRRef, _KeyField
de _Documento140_VT1385
agrupar por _Document140_IDRRef, _KeyField
tendo contagem(*) > 1
Use-o para descobrir os valores das colunas _Document140_IDRRef, _KeyField, registros duplicados (id, chave).

Usando a solicitação:
Código SQL S_elect *
de _Documento140_VT1385
ou _Document140_IDRRef = id2 e _KeyField = key2 ou ...
observe os valores das outras colunas das entradas duplicadas.
Se ambas as entradas tiverem valores significativos e os valores forem diferentes, altere o valor _KeyField para ser exclusivo. Para fazer isso, determine o valor máximo ocupado de _KeyField (keymax):
Código SQL S_elect max(_KeyField)
de _Documento140_VT1385
onde _Document140_IDRRef = id1
Substitua o valor _KeyField em uma das entradas duplicadas pelo correto:
Atualização do código SQL _Document140_VT1385
definir _KeyField = keymax + 1
Aqui _LineNo1386 = é uma condição adicional que permite selecionar um dos dois registros repetidos.

Se uma (ou ambas) das entradas duplicadas tiver um significado obviamente incorreto, ela deverá ser removida:
Exclusão de código SQL de _Document140_VT1385
onde _Document140_IDRRef = id1 e _LineNo1386 = lineno1
Se as entradas duplicadas tiverem os mesmos valores em todas as colunas, você precisará deixar uma delas:
Código SQL S_elect distinto *
em #tmp1
de _Documento140_VT1385
onde _Document140_IDRRef = id1 e _KeyField = key1

Excluir de _Document140_VT1385
onde _Document140_IDRRef = id1 e _KeyField = key1

Eu_insiro em _Document140_VT1385
S_elect #tmp1

Tabela D_rop #tmp1

O procedimento descrito deve ser realizado para cada par de registros duplicados.

2.2.3. Segundo exemplo:
Código SQL S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description
DE _Referência8_
GRUPO POR _IDRRef, _Descrição
TENDO (CONTAR(*) > 1)

2.3.4 Um exemplo de determinação de registros não exclusivos usando uma consulta 1C:Enterprise:
Código 1C v 8.x SELECIONE Directory.Link
DE Directory.Directory AS Diretório
GRUPO POR Diretório.Link
TENDO QUANTIDADE(*) > 1