Всем доброе время суток !

Ситуация следующая.

Обратился ко мне родственник. Он мелкий предприниматель. Вел учет на древней "Торговля и склад". База была ДБФ. Учет вел несколько лет, до тех пор пока не уперся в лимит размера ДБФ файла. База выдала ошибку и вылетела. Далее как обычно бывает в таких ситуациях - человек подумал что он самый умный, зачем спрашивать знающих людей ? Есть интернет сейчас найду сам решение проблемы. Открыл Яндекс, вбил "ошибка базы 1С 7.7 решить", ну и "нашел" способ решения - сделать выгрузку-загрузку базы. Выгрузить то он выгрузил, но вот только загрузка уже не происходит - лимит ДБФ файла. Но ДБФ базу уже убил.

Тут он понял что дело пхнет керосином и надо обращаться к специалистам. Обратился ко мне. Я говорю - давай файл выгрузки починю.

Поднимаю скульную базу, гружу в нее архив и получаю сообщение "CREATE UNIQUE INDEX terminated because a duplicate key was found for the object name 'dbo.1sjourn'". С прекращением загрузки естественно.

Если бы была ДБФ база можно было бы поправить эти индексы в ней. Но базу шаловливые ручки убили.


Как можно при загрузке данных отключить проверку индексов на уникальность ?

какой селект, какие чек дб, ВЫ ОБ ЧОМ????
базы НЕТ. есть только выгрузка. которая при загрузке в скл дает ошибку(!) неуникальности primary key.

(0): а почему в дбф не грузится? если еще не поставили - попробуйте установить kernel33x и потом загрузить...

ну или в самом пиковом варианте - придется заспаковывать выгрузку, и в дат-файле текстовым процессором и самостоятельно слепленной какой-нито приблудой искать в 1sjourn-секции одинаковые iddoc, а потом вычищать их отовсюду.
кстати - загрузка у вас должна оборваться на каком-то документе. после загрузки с ошибкой - запуститесь в режиме предприятия. если запустится - идите в общий журнал и смотрите на последний (загруженный) документ. это даст приблизительные данные для поиска в дат-файле.

"заспаковывать" - прикольная очепятка. распаковывать конечно же.

ну т.е. по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него дожен быть дублирующийся iddoc. можно попробовать его вычистить - и снова попробовать загрузить. если не загрузится - снова искать очередной дубликат ddoc, вычищать его из дат-файла, и т.д.
кстати. чтобы грузить прямо из дат-файла - используйте приблуду romix-а, она позволяет делать выгрузку-загрузку в большой дат-файл без его упаковки.

в (9) первый абзац читать вот так:
ну т.е. по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него дожен быть дублирующийся iddoc. можно попробовать его вычистить - и снова попробовать загрузить. если не загрузится - снова искать последний документ в общем журнале, потом - по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него... и т.д.

(5) >базы НЕТ. есть только выгрузка. которая при загрузке в скл дает ошибку(!) неуникальности primary key.

Вот именно.

Была бы база (хоть ДБВ хоть скуль) убрать неуникальные данные раз плюнуь.

(6) >а почему в дбф не грузится

Потому что один из ДБФ файлов превысил 2 Гб. Проблемы с ДБФ базой начались именно по этой причине. Она отказалась работать. Ну и человек не долго думая решид сделать выгрузку-загрузку. Когда загрузка висела уже второй день он понял что нужно обратиться к специалисту.

распаковать выгрузку. убить внутри выгрузки R*328. загрузить в ДБФ

(13) Ты не поверишь, но в выгрузке нет никаких rg

(0) отключи уникальность индекса в скуле и грузи дальше. Потом выкосишь левую запись

Ну или в дат файле поправь..

(14) я догадываюсь.

убить нахрен партионку и все в дат-файле

(18) не все так просто, движения в каждом документе..умаешься вырезать

чисто теоретические варианты):
1) запустить 1С под отладчиком (ollydbg и иже) и поймать момент, в который оно отправляет скулю команду на создание индекса. Понятно, что грубое нарушение лиц.соглашения и вообще, это такое
2) посмотреть в сторону Триггеры DDL: https://docs.microsoft.com/ru-ru/sql/relational-databases/triggers/ddl-triggers?view=sql-server-ver15. По идее и наверное можно поймать событие создание индекса и при этом найти/очистить все дубли. Или, в идеале вообще дропнуть этот индекс.
3)Можно бесконечный скрипт запустить в Студии, который будет искать/удалять дубли в искомой таблице, и надеяться, что он отработает до начала создания индекса (а они емнип, создаются уже в конце загрузки - интересно, кстати, в случае ошибки данные тоже откатываются или нет). Но здесь надо как-то убрать single_user у базы (если такое возможно)

Проще просто отключить индекс..и усё. После загрузки удалить дубли и включить индекс. Но не факт, что там других ошибок нет, из за которых в скуль не всосёт.

еще можно (теоретически) поймать все "входящие" запросы профайлером, и выполнить их уже самому))

(21) вопрос в том, откатывает ли 1С данные в случае этой ошибки. Если нет, то да

(15) >отключи уникальность индекса в скуле и грузи дальше

Так я в (0) и спросил как это сделать при загрузке.

(24) да вроде никак.
у тебя 1sjourn уже загружена в скуль, посмотри какой там ID задублирован.
потом можно попробовать каким-нить потоковым редактором заменитьэтот ID в dat-файле.

(25) неа. там догружает до дубля и рвет.

могу попробовать потрахаться с этой проблемой.

(21): после загрузки - проще (имхо) собрать список дублей iddoc в 1sjourn, а потом в дат-файле тупо повырезать строки с такими iddoc" - нэ?

(26) не думаю. Думаю в 1С не драки сидят, и индексы создают уже после загрузки.

(28)+ а. ну да, а потом загрузить из исправленного дат-файла
прим: там вроде из 1sjourn можно инфу выдернуть с номером-датой-чемтоеще документа... так, чтобы знать, что удалил
(29) я пробовал.

хотя можно это и проверить. в топике же написано, что "CREATE UNIQUE INDEX terminated because a duplicate key was found for the object name 'dbo.1sjourn'""
это значит, что индекс создавался уже на загруженные данные.

(28) не, тогда даст ощибку парсинга. Тем более что в dat файле id не 16-тиричный а десятичный.
что-то типа "124|".
так что менять надо с умом.

(27) > могу попробовать потрахаться с этой проблемой.
+ не за бесплатно конечно.

Триггерами, похоже реально разрулить.
Проблема в том, что на CREATE_INDEX вешать похоже, бесполезно, т.к. ошибка вылезает перед триггером.
И на таблицу не повесишь, потому что она пересоздается в процессе загрузки.
Но, можно создать триггер DDL на CREATE_TABLE, и уже в нем создать триггер DML на dbo.1sjourn, где проверять дубли в inserted

(34): какую ошибку парсинга?? тупо вырезать все блоки и строки с дубликатным iddoc...

(36): ухты. это ж вроде полшага от универсального решения довольно распространенной проблемы...

(38) Что-то вроде такого получается:

use test_dev;
GO

drop trigger if exists trigg_table_create ON DATABASE
GO
drop trigger if exists tr_jrn_insert
GO
drop table if exists _1sjourn
GO

CREATE TRIGGER trigg_table_create
ON DATABASE
FOR CREATE_TABLE  
AS
        
exec (
    'create trigger tr_jrn_insert on dbo._1sjourn
        after insert
            as
                delete from _1sjourn -- здесь логика удаления дублей//копируются в др. таблицу '
)
    
GO

create table _1sjourn (_id int)
insert into _1sjourn(_id) values (1), (1), (2)

Остается только понять, что это именно нужная таблица в FOR CREATE_TABLE (возможно, это через EVENTDATA() можно узнать или тупо наличие таблицы/триггера проверять), ну и собственно логику очистки/бэкапа дубле в триггере данных прописать )

(39) ну да, условие можно сделать наподобие:

IF EVENTDATA().value('(/EVENT_INSTANCE[1]/ObjectName[1])', 'nvarchar(150)') = '_1sjourn'
         exec (

Вот в принципе, вроде рабочий вариант, надо смотреть, как оно будет работать на реальных данных.  сюда еще можно прикрутить сохранение дублей в левую таблицу перед удалением



drop trigger if exists trigg_table_create ON DATABASE
GO
drop trigger if exists tr_jrn_insert
GO
drop table if exists _1sjourn
GO
drop table if exists _journ_doubles_table
GO

CREATE TRIGGER trigg_table_create
ON DATABASE
FOR CREATE_TABLE  
AS

    IF EVENTDATA().value('(/EVENT_INSTANCE[1]/ObjectName[1])', 'nvarchar(150)') = '_1sjourn'
         exec (
            'create trigger tr_jrn_insert on dbo._1sjourn
                after insert
                    as  
                        delete from _1sjourn
                        where _id in (select _id from _1sjourn group by _id having count(*) >1)
            '
        )

GO

--ТЕСТ:
create table _1sjourn (_id int)
insert into _1sjourn(_id) values (1), (1), (2), (3), (2)
select * from _1sjourn

)

Интересно, а если просто отключить создание уникальных индексов?
Вот тут эта строковая константа в BkEnd.dll https://gyazo.com/92a8569384b8c46952fbfcd8ee4cdac4 находится.
Судя по всему она используется при создании таблиц по 1Cv7.DDS. Забить ее пробелами. ИМХО Должно загрузится.

(37) ты их сначала найди попробуй.

(12) Есть же приблуда убирающая это ограничение, может стоит попробовать её?

(44) Есть которые до 2ГБ а выше для дбф вроде и нет ничего

(45) Есть dbeng32, от wirth. До 6 гигов файлы на тесте разгонял. Только это не классические dbf, их редкие программы просмотра dfb смогут осилить.

(45) Есть 4gb_patch, я его пробовал для примерно такого же случая на домашнем сервере, всё получилось, но у меня была вся папка базы, а не дт.

(47) дт - это для 8-ки вроле?
А выложи куда-нибудь этот патч на автообменник - а то как раз скоро 2 гб подойдет может и свертку делать пока не надо.

(48) Я образно выразился.

(47) этот патч (я его нашел) он же просто позволяет 1С работать с большим количеством оперативной памяти. А причем тут ограничение дбф в 2 ГБ?

Если кому надо - могу выложить

(50) Если база загрузится в дбф, то дальше можно будет подрихтовать файлы.

(52) Ну если она больше 2 гб - разве она может загрузиться? А, ну хотя это ж просто распаковать что ли? ведь она итоги тут же начнет пересчитывать.

Вы с 2G все в кашу смешали. И память, и размер файлов dbf и размер выгрузки...

Вот 3 рабочих рецепта:

Для увеличения памяти 1С больше 2Gb: 4Gb Patch NTCore https://ntcore.com/?page_id=371
Для загрузки и выгрузки dt больше 2Gb: ConfigSpy от АЛьФ http://www.dorex.pro/?projects&configspy&download
Для работы 1C с файлами dbf больше 2Gb: dbeng32 от Wirth https://cloud.mail.ru/public/3mVX/4trK45on8


(54) думаешь загрузится выгрузка в dbf с неуникалльными ID,

(55) В dbf не знаю. В (42) возможно сработает для sql. Если где-то потом не порушиться, но уже по другой причине.

(56) можно проверить: наваять мини конфу и поправить dat-файл.

(57) Ага! Испортил в выгрузке IDDOC, загрузилось https://gyazo.com/8cf8187eaff732ea2d511d9a104d7c40

(58) в дбф и без этого загрузилось бы..там не пасутся дубли ид

а в скуле, старше 2005 можно просто отключить использование индекса

(52) >Если база загрузится в дбф, то дальше можно будет подрихтовать файлы

В ДБФ база сейчас без плясок с бубном не загрузится. Размер таблицы превысил 2 Гб.

Про
>Для работы 1C с файлами dbf больше 2Gb: dbeng32 от Wirth

раньше не знал.

(60) >в скуле, старше 2005

А как это сделать ?

Сейчас ситуация следующая.

После вылета при загрузке по причине неуникальных ключей в базе таблицы есть.

Запросом к _1sjourn я вижу эти дубли.
выгрузка
Удалить их не проблема.

Есть только один вопрос - вылет при загрузке по причине неуникальных ключей происходит на этапе когда все данные уже загружены в базу и происходит создание индексов по ним или когда загружена только часть данных ? Если первое то тогда все просто - удалить дубли в таблице, выгрузка, загрузка.

(63) На sql видимо то же самое https://gyazo.com/335416f0617727b3d94caa90b0a0d44f
Индексация идет после загрузки всех справочников и документов. После индексации пересчеты перекрестных ссылок и итогов.

(63) в файловой нет ограничений на таблицах, поэтому грузится все и обламываается на индексации. на сиквельной - ограничение по уникальности ключа - это свойство таблицы, поэтому обламывается на загрузке

(65) Нет же! В (0) написано что sql ругается на создание индекса, а в (63) написано что видны дубли. Т.е. индексация проходит все таки после загрузки всех данных.
Можно ConfigSpy`ем проверить, но почти уверен что будет так же как и в (64).

(63) > ? Если первое то тогда все просто - удалить дубли в таблице, выгрузка, загрузка.

удали дубли, выгрузи данные и сравни dat файлы по размеру.
если дельта будет не большая, значит все загружено.

(66) там первый индекс кластерный, по нему и контролируется. значит, дубль попадает в некластерный индекс.
впрочем, за давностью лет могу ошибаться - такую же проблему решали с админом  ровно 12 лет назад - в ноябрьские праздники 2008 года...

(41) надо не delete делать записи, а update iddoc у дубля, токма еще и в тч доков и в шапке подменять

и ..проще после сообщения в (0) найти эти id в dat файле и поменять на мах(iddoc)+1

отключите создание индекса с помощью ddl триггера
http://catalog.mista.ru/1c/articlmes/936914/

удалите дубли создайте индекс.

(54) Уже не рабочие. Повтори, пожалуйста.

(72) Миста добавила спереди forum.mista.ru/" Сотри.

(55) >думаешь загрузится выгрузка в dbf с неуникалльными ID

Да загружается.

С помощью
>Для работы 1C с файлами dbf больше 2Gb: dbeng32 от Wirth

который снимает лимит на размер ДБФ файла в 2 Гб

Данные загрузились, сейчас регистры за 15 лет существования базы пересчитывает.

(69) не, надо просто перед delete select into в левую таблицу. А уже из этой таблицы после загрузки скриптами и руками смотреть что есть что, в т.ч. цепляясь к основным таблицам

(43) >ты их сначала найди попробуй

Да с этим никаких проблем нет.

use MyBase
go
select iddoc, count(*)
from _1sjourn
group by iddoc
having count(*)>1

(70) >найти эти id в dat файле и поменять на мах(iddoc)+1

Я в скульной базе так и делал.

Но как правильно заметили в (69) необходимо делать

>update iddoc у дубля, токма еще и в тч доков и в шапке подменять

С учетом того что в и в тч доков и в шапке iddoc у задублированных записей одинаковые приходится делать сначала замену iddoc в 1sjourn, затем заменять в тч доков и в шапке iddoc у задублированных записей на новые значения iddoc этих записей из 1sjourn.

Вот хочу сейчас на ДБФ эту же схему сделать. На мой взгляд на ДБФ это даже удобней править.

(76) > ты их сначала найди попробуй
Речь шла о поиске в dat-файле.

(77) занафига ?
Тупо в 1sjourn проапдейть табличку, а также соответствующие dh и dt (если они есть, конечно). Потом прибей несоздавшийся индекс в 1sjourn, зайди в пофигуратор, сделай загрузить измененную конфигурацию - укажи на мд из каталога с базы, сохрани, зайди монопольно. Усё. Оно само реструктуризирует и создаст заново нужный индекс ну и итоги потом пересчитаешь..

если оно само не посчитает.

(77) > С учетом того что в и в тч доков и в шапке iddoc у задублированных записей одинаковые приходится делать сначала замену iddoc в 1sjourn, затем заменять в тч доков и в шапке iddoc у задублированных записей на новые значения iddoc этих записей из 1sjourn.

Ну удачи :)
А как ты узнаешь у какого дока id оригинальный, а у какого не тот? :)
возможно запись задублирована только в 1sjourn

Хотя проще в dat поменять, тогда оно само шапку и всё остальное нормально слепит..а так, еще и записи проводок/операций/регистров..нужно править, по идее и значения периодики, установленной документом

(82) Вот именно.

Но тут свои сложности, т.к. id-ы просто так не найти, т.к. у всех таблиц нумерация с 0 идет. И id справочника может совпасть с id документа.

(84) ну, в dat файлике достаточно всё прозрачно

кто-то даже конвертер писал, по переводу его в xml и обратно..

ну и толку то вы найдете iddoc-дубликаты и все iddoc-дубликаты поменяете... на мах(iddoc)+1 - дубликаты!

(87) ? как это дубликаты ? Ты всегда +1 прибавляй и не будет дублей..це же очевидно :)

(87): это в какой таблице? ну, давай, итак.
макс.ид=10 (ну допустим).
1. в 1sjourn - нашли, допустим, дубликат, два раза iddoc=2.один меняем на 11, второй на 12.
2. оба, допустим, документы одного вида. идем в dh - а там две двойки. какую из них менять на 11 какую на 12?.. ну, допустим, кинули монетку - угадали. дальше...
3. идем в dh - ойёоо, а там куча двоек. кикие из них менять на 11, какие на 12?..
4. ай, перекрестились - идем по другим тамлицам.. и какие из двоек менять на 11 а какие на 12???

(89)+: это я предположил, что ты в (88) ошибся, предлжив сплошняком по всем таблицам все двойки тупо потоком поменять на совершенно разные "всегда +1 прибавляй" - тогда б данные вообще тупо развалились бы..

(89) во всех вестимо..но проще в одном месте - в dat файлике :)

И..посмотреть сперва что за вид дока и нужен ли он вообще, чтоб этим морочится и делает ли он движуху и какой там closed стоит и какие флаги в регистрах.. ну и т.д

(91),(92): ты не ответил на (89). там по пунктам. можно вместо таблиц полагать секции дат-файла.
если тупо все по потоку двойки с автоинкрементом переназначить - то данные развалятся, как это отмечено в (90). иного спооба различить в разных местах - какую из двоек менять на 11 а какую на 12 (документ одного вида). и?

я уже не знаю как объяснять. ну на примере (89).
находим первую двойку 2-ку в строке, относящейся к таблице общего журнала, меняем на 11...
ищем дальше - находим двойку в строке, относящейся к таблице общего журнала, меняем на 12...
ищем дальше - находим двойку в строке, относящейся к строке dh-таблицы, меняем на 13 (и - опа, а такой строки в общем журнале нет. ну ладно. забили, поехали дальше...
ищем дальше - находим двойку в строке, относящейся к строке dt-таблицы , меняем на 14... и - опа, а ведь такого ид-а в сооответствующем dh нет - и эта строка табличной части относится к какому-то несуществующему документу которого и в журнале тоже нет...
идем дальше... нет. уже никто никуда не идет. бо данные раз.ва.ли.ва.ют.ся.

(91) А в dat-файле ты сможешь понять, какая именно из строк дубля - условно правильная? Мне кажется, тут две задачи: 1) избежать ошибки уникальности, чтобы загрузка выполнилась штатно. 2) Анализ эти дублей, с целью  корректировки данных . B Скуль для п. 2 подходит как нельзя лучше.
Если же просто делать id+1 по top 1, то ситуация еще больше запутается, может получиться, например, что есть движения в rg по помеченному документу и т.п.

1 - пишите, что базы нет, а куда она делась, удалили что ли ? Если есть, но не запускается из за большого файла, то можно и с ней поколдлвать
2 - если все таки базы нет, то я бы последовал  совету Епрст, отключил контроль уникальности, загрузил базу в sql, а там уже смотреть что дублируется
Может и менять ничtго не надо, просто лишнее удалить. Когда есть база, можно что то думать и решать, а когда нет, то можно долго обсуждать. но на одном
иесте. Выгрузка все равно уже устарела, надо будет базу догонять первичкой, ну также можно догнать и кривой день, когда случился дубль и база вылетела
Надо загрузить ))

(94) Всё правильно.
Поэтому править лучше в DAT файле, там гораздо проще будет в данной ситуации

(97): кхм.. а там у меня в формлровках - про строи дат-файла. и про строки таблиц. т.е. и то и то - расползается. :/

+ (97) Там у доков ID только в строке шапки записан, остальное - "экстраполируется" платформой при загрузке данных.
Если я правильно помню.

(99): уверен? а в периодике - тоже?

(100) Ну нет конечно жеж)
поэтому и пишу: "Если я правильно помню")
Но в данном случае, сдается мне, на периодику можно тупо забить - не согласен?
Разницы особой (для "конечных" данных) - не будет.

+(101) Ему же главное ЗАГРУЗИТЬ данные, и получить картину на ТЕКУЩИЙ момент)

Так может в DDS сделать индекс не уникальным и запаковать обратно?

(103) Извините, фигню спорол