Вход | Регистрация
    1  2   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Неуникальные индексы при загрузке базы из архива

v7: Неуникальные индексы при загрузке базы из архива
Я
   ЧессМастер
 
06.11.20 - 22:00
Всем доброе время суток !

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

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

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

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

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


Как можно при загрузке данных отключить проверку индексов на уникальность ?
   Чрут
 
1 - 06.11.20 - 22:36
Может я не прав но если выкинуло ошибку по индексам значит данные уже есть. Чек db делай
   Чрут
 
2 - 06.11.20 - 22:41
Погугли тут на мисте темы про проверку и починку скульной базы. А можно и руками пошарашить запрос к таблице
1sjourn.
   Чрут
 
3 - 06.11.20 - 22:44
+  пример запроса
select
  count(1) as count
from
  dbo.1sjourn
group by
   <имя поля по которому должны строится уникальные индексы>
having
   count > 1
Примерно так. В синтаксисе мог ошибся оч редко на скуле запросы делаю
   Чрут
 
4 - 06.11.20 - 22:48
Пардон муа в запросе выше не увидишь виновника...
Добавь в вывод поле группировки
select
  count(1) as count,
  journ.<имя поля по которому должны строится уникальные индексы>
from
  dbo.1sjourn as journ
group by
   <имя поля по которому должны строится уникальные индексы>
having
   count > 1
   Cthulhu
 
5 - 06.11.20 - 22:54
какой селект, какие чек дб, ВЫ ОБ ЧОМ????
базы НЕТ. есть только выгрузка. которая при загрузке в скл дает ошибку(!) неуникальности primary key.
   Cthulhu
 
6 - 06.11.20 - 22:56
(0): а почему в дбф не грузится? если еще не поставили - попробуйте установить kernel33x и потом загрузить...
   Cthulhu
 
7 - 06.11.20 - 23:00
ну или в самом пиковом варианте - придется заспаковывать выгрузку, и в дат-файле текстовым процессором и самостоятельно слепленной какой-нито приблудой искать в 1sjourn-секции одинаковые iddoc, а потом вычищать их отовсюду.
кстати - загрузка у вас должна оборваться на каком-то документе. после загрузки с ошибкой - запуститесь в режиме предприятия. если запустится - идите в общий журнал и смотрите на последний (загруженный) документ. это даст приблизительные данные для поиска в дат-файле.
   Cthulhu
 
8 - 06.11.20 - 23:01
"заспаковывать" - прикольная очепятка. распаковывать конечно же.
   Cthulhu
 
9 - 06.11.20 - 23:05
ну т.е. по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него дожен быть дублирующийся iddoc. можно попробовать его вычистить - и снова попробовать загрузить. если не загрузится - снова искать очередной дубликат ddoc, вычищать его из дат-файла, и т.д.
кстати. чтобы грузить прямо из дат-файла - используйте приблуду romix-а, она позволяет делать выгрузку-загрузку в большой дат-файл без его упаковки.
   Cthulhu
 
10 - 06.11.20 - 23:07
в (9) первый абзац читать вот так:
ну т.е. по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него дожен быть дублирующийся iddoc. можно попробовать его вычистить - и снова попробовать загрузить. если не загрузится - снова искать последний документ в общем журнале, потом - по (7) ищете 1sjourn-секции дат-файла последний загруженный док, сразу после него... и т.д.
   ЧессМастер
 
11 - 06.11.20 - 23:20
(5) >базы НЕТ. есть только выгрузка. которая при загрузке в скл дает ошибку(!) неуникальности primary key.

Вот именно.

Была бы база (хоть ДБВ хоть скуль) убрать неуникальные данные раз плюнуь.
   ЧессМастер
 
12 - 06.11.20 - 23:23
(6) >а почему в дбф не грузится

Потому что один из ДБФ файлов превысил 2 Гб. Проблемы с ДБФ базой начались именно по этой причине. Она отказалась работать. Ну и человек не долго думая решид сделать выгрузку-загрузку. Когда загрузка висела уже второй день он понял что нужно обратиться к специалисту.
   Злопчинский
 
13 - 06.11.20 - 23:31
распаковать выгрузку. убить внутри выгрузки R*328. загрузить в ДБФ
   Ёпрст
 
14 - 06.11.20 - 23:37
(13) Ты не поверишь, но в выгрузке нет никаких rg
   Ёпрст
 
15 - 06.11.20 - 23:38
(0) отключи уникальность индекса в скуле и грузи дальше. Потом выкосишь левую запись
   Ёпрст
 
16 - 06.11.20 - 23:38
Ну или в дат файле поправь..
   Злопчинский
 
17 - 07.11.20 - 00:24
(14) я догадываюсь.
   Злопчинский
 
18 - 07.11.20 - 00:25
убить нахрен партионку и все в дат-файле
   Ёпрст
 
19 - 07.11.20 - 00:38
(18) не все так просто, движения в каждом документе..умаешься вырезать
   youalex
 
20 - 07.11.20 - 01:08
чисто теоретические варианты):
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 - 07.11.20 - 01:23
Проще просто отключить индекс..и усё. После загрузки удалить дубли и включить индекс. Но не факт, что там других ошибок нет, из за которых в скуль не всосёт.
   youalex
 
22 - 07.11.20 - 01:25
еще можно (теоретически) поймать все "входящие" запросы профайлером, и выполнить их уже самому))
   youalex
 
23 - 07.11.20 - 01:26
(21) вопрос в том, откатывает ли 1С данные в случае этой ошибки. Если нет, то да
   ЧессМастер
 
24 - 07.11.20 - 01:41
(15) >отключи уникальность индекса в скуле и грузи дальше

Так я в (0) и спросил как это сделать при загрузке.
   trdm
 
25 - 07.11.20 - 02:20
(24) да вроде никак.
у тебя 1sjourn уже загружена в скуль, посмотри какой там ID задублирован.
потом можно попробовать каким-нить потоковым редактором заменитьэтот ID в dat-файле.
   Cthulhu
 
26 - 07.11.20 - 02:21
(25) неа. там догружает до дубля и рвет.
   trdm
 
27 - 07.11.20 - 02:21
могу попробовать потрахаться с этой проблемой.
   Cthulhu
 
28 - 07.11.20 - 02:21
(21): после загрузки - проще (имхо) собрать список дублей iddoc в 1sjourn, а потом в дат-файле тупо повырезать строки с такими iddoc" - нэ?
   trdm
 
29 - 07.11.20 - 02:22
(26) не думаю. Думаю в 1С не драки сидят, и индексы создают уже после загрузки.
   Cthulhu
 
30 - 07.11.20 - 02:23
(28)+ а. ну да, а потом загрузить из исправленного дат-файла
прим: там вроде из 1sjourn можно инфу выдернуть с номером-датой-чемтоеще документа... так, чтобы знать, что удалил
(29) я пробовал.
 
 Рекламное место пустует
   trdm
 
31 - 07.11.20 - 02:23
хотя можно это и проверить. в топике же написано, что "CREATE UNIQUE INDEX terminated because a duplicate key was found for the object name 'dbo.1sjourn'""
это значит, что индекс создавался уже на загруженные данные.
   trdm
 
34 - 07.11.20 - 02:33
(28) не, тогда даст ощибку парсинга. Тем более что в dat файле id не 16-тиричный а десятичный.
что-то типа "124|".
так что менять надо с умом.
   trdm
 
35 - 07.11.20 - 02:36
(27) > могу попробовать потрахаться с этой проблемой.
+ не за бесплатно конечно.
   youalex
 
36 - 07.11.20 - 03:12
Триггерами, похоже реально разрулить.
Проблема в том, что на CREATE_INDEX вешать похоже, бесполезно, т.к. ошибка вылезает перед триггером.
И на таблицу не повесишь, потому что она пересоздается в процессе загрузки.
Но, можно создать триггер DDL на CREATE_TABLE, и уже в нем создать триггер DML на dbo.1sjourn, где проверять дубли в inserted
   Cthulhu
 
37 - 07.11.20 - 03:39
(34): какую ошибку парсинга?? тупо вырезать все блоки и строки с дубликатным iddoc...
   Cthulhu
 
38 - 07.11.20 - 03:40
(36): ухты. это ж вроде полшага от универсального решения довольно распространенной проблемы...
   youalex
 
39 - 07.11.20 - 04:47
(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() можно узнать или тупо наличие таблицы/триггера проверять), ну и собственно логику очистки/бэкапа дубле в триггере данных прописать )
   youalex
 
40 - 07.11.20 - 05:27
(39) ну да, условие можно сделать наподобие:

IF EVENTDATA().value('(/EVENT_INSTANCE[1]/ObjectName[1])', 'nvarchar(150)') = '_1sjourn'
         exec (
   youalex
 
41 - 07.11.20 - 05:51
Вот в принципе, вроде рабочий вариант, надо смотреть, как оно будет работать на реальных данных.  сюда еще можно прикрутить сохранение дублей в левую таблицу перед удалением


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

)
   Djelf
 
42 - 07.11.20 - 08:13
Интересно, а если просто отключить создание уникальных индексов?
Вот тут эта строковая константа в BkEnd.dll https://gyazo.com/92a8569384b8c46952fbfcd8ee4cdac4 находится.
Судя по всему она используется при создании таблиц по 1Cv7.DDS. Забить ее пробелами. ИМХО Должно загрузится.
   trdm
 
43 - 07.11.20 - 09:05
(37) ты их сначала найди попробуй.
   GreyK
 
44 - 07.11.20 - 09:17
(12) Есть же приблуда убирающая это ограничение, может стоит попробовать её?
   tgu82
 
45 - 07.11.20 - 09:35
(44) Есть которые до 2ГБ а выше для дбф вроде и нет ничего
   Djelf
 
46 - 07.11.20 - 09:40
(45) Есть dbeng32, от wirth. До 6 гигов файлы на тесте разгонял. Только это не классические dbf, их редкие программы просмотра dfb смогут осилить.
   GreyK
 
47 - 07.11.20 - 09:45
(45) Есть 4gb_patch, я его пробовал для примерно такого же случая на домашнем сервере, всё получилось, но у меня была вся папка базы, а не дт.
   tgu82
 
48 - 07.11.20 - 09:58
(47) дт - это для 8-ки вроле?
А выложи куда-нибудь этот патч на автообменник - а то как раз скоро 2 гб подойдет может и свертку делать пока не надо.
   GreyK
 
49 - 07.11.20 - 10:03
(48) Я образно выразился.
   tgu82
 
50 - 07.11.20 - 10:05
(47) этот патч (я его нашел) он же просто позволяет 1С работать с большим количеством оперативной памяти. А причем тут ограничение дбф в 2 ГБ?
   tgu82
 
51 - 07.11.20 - 10:05
Если кому надо - могу выложить
   GreyK
 
52 - 07.11.20 - 10:14
(50) Если база загрузится в дбф, то дальше можно будет подрихтовать файлы.
   tgu82
 
53 - 07.11.20 - 10:20
(52) Ну если она больше 2 гб - разве она может загрузиться? А, ну хотя это ж просто распаковать что ли? ведь она итоги тут же начнет пересчитывать.
   Djelf
 
54 - 07.11.20 - 10:41
Вы с 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

   trdm
 
55 - 07.11.20 - 10:50
(54) думаешь загрузится выгрузка в dbf с неуникалльными ID,
   Djelf
 
56 - 07.11.20 - 10:54
(55) В dbf не знаю. В (42) возможно сработает для sql. Если где-то потом не порушиться, но уже по другой причине.
   trdm
 
57 - 07.11.20 - 10:56
(56) можно проверить: наваять мини конфу и поправить dat-файл.
   Djelf
 
58 - 07.11.20 - 11:04
(57) Ага! Испортил в выгрузке IDDOC, загрузилось https://gyazo.com/8cf8187eaff732ea2d511d9a104d7c40
   Ёпрст
 
59 - 07.11.20 - 11:32
(58) в дбф и без этого загрузилось бы..там не пасутся дубли ид
   Ёпрст
 
60 - 07.11.20 - 11:33
а в скуле, старше 2005 можно просто отключить использование индекса
 
 Рекламное место пустует
   ЧессМастер
 
61 - 07.11.20 - 12:17
(52) >Если база загрузится в дбф, то дальше можно будет подрихтовать файлы

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

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

раньше не знал.
   ЧессМастер
 
62 - 07.11.20 - 12:19
(60) >в скуле, старше 2005

А как это сделать ?
   ЧессМастер
 
63 - 07.11.20 - 12:25
Сейчас ситуация следующая.

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

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

Есть только один вопрос - вылет при загрузке по причине неуникальных ключей происходит на этапе когда все данные уже загружены в базу и происходит создание индексов по ним или когда загружена только часть данных ? Если первое то тогда все просто - удалить дубли в таблице, выгрузка, загрузка.
   Djelf
 
64 - 07.11.20 - 12:41
(63) На sql видимо то же самое https://gyazo.com/335416f0617727b3d94caa90b0a0d44f
Индексация идет после загрузки всех справочников и документов. После индексации пересчеты перекрестных ссылок и итогов.
   Mikeware
 
65 - 07.11.20 - 12:48
(63) в файловой нет ограничений на таблицах, поэтому грузится все и обламываается на индексации. на сиквельной - ограничение по уникальности ключа - это свойство таблицы, поэтому обламывается на загрузке
   Djelf
 
66 - 07.11.20 - 12:54
(65) Нет же! В (0) написано что sql ругается на создание индекса, а в (63) написано что видны дубли. Т.е. индексация проходит все таки после загрузки всех данных.
Можно ConfigSpy`ем проверить, но почти уверен что будет так же как и в (64).
   trdm
 
67 - 07.11.20 - 12:56
(63) > ? Если первое то тогда все просто - удалить дубли в таблице, выгрузка, загрузка.

удали дубли, выгрузи данные и сравни dat файлы по размеру.
если дельта будет не большая, значит все загружено.
   Mikeware
 
68 - 07.11.20 - 14:03
(66) там первый индекс кластерный, по нему и контролируется. значит, дубль попадает в некластерный индекс.
впрочем, за давностью лет могу ошибаться - такую же проблему решали с админом  ровно 12 лет назад - в ноябрьские праздники 2008 года...
   Ёпрст
 
69 - 07.11.20 - 15:24
(41) надо не delete делать записи, а update iddoc у дубля, токма еще и в тч доков и в шапке подменять
   Ёпрст
 
70 - 07.11.20 - 15:25
и ..проще после сообщения в (0) найти эти id в dat файле и поменять на мах(iddoc)+1
   МихаилМ
 
71 - 07.11.20 - 15:30
отключите создание индекса с помощью ddl триггера
http://catalog.mista.ru/1c/articlmes/936914/

удалите дубли создайте индекс.
   obs191
 
72 - 07.11.20 - 15:39
(54) Уже не рабочие. Повтори, пожалуйста.
   Djelf
 
73 - 07.11.20 - 16:43
(72) Миста добавила спереди forum.mista.ru/" Сотри.
   ЧессМастер
 
74 - 07.11.20 - 17:22
(55) >думаешь загрузится выгрузка в dbf с неуникалльными ID

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

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

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

Данные загрузились, сейчас регистры за 15 лет существования базы пересчитывает.
   youalex
 
75 - 07.11.20 - 18:01
(69) не, надо просто перед delete select into в левую таблицу. А уже из этой таблицы после загрузки скриптами и руками смотреть что есть что, в т.ч. цепляясь к основным таблицам
   ЧессМастер
 
76 - 07.11.20 - 18:15
(43) >ты их сначала найди попробуй

Да с этим никаких проблем нет.
use MyBase
go
select iddoc, count(*)
from _1sjourn
group by iddoc
having count(*)>1
   ЧессМастер
 
77 - 07.11.20 - 18:24
(70) >найти эти id в dat файле и поменять на мах(iddoc)+1

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

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

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

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

Вот хочу сейчас на ДБФ эту же схему сделать. На мой взгляд на ДБФ это даже удобней править.
   trdm
 
78 - 07.11.20 - 18:43
(76) > ты их сначала найди попробуй
Речь шла о поиске в dat-файле.
   Ёпрст
 
79 - 07.11.20 - 21:44
(77) занафига ?
Тупо в 1sjourn проапдейть табличку, а также соответствующие dh и dt (если они есть, конечно). Потом прибей несоздавшийся индекс в 1sjourn, зайди в пофигуратор, сделай загрузить измененную конфигурацию - укажи на мд из каталога с базы, сохрани, зайди монопольно. Усё. Оно само реструктуризирует и создаст заново нужный индекс ну и итоги потом пересчитаешь..
   Ёпрст
 
80 - 07.11.20 - 21:45
если оно само не посчитает.
   trdm
 
81 - 07.11.20 - 21:50
(77) > С учетом того что в и в тч доков и в шапке iddoc у задублированных записей одинаковые приходится делать сначала замену iddoc в 1sjourn, затем заменять в тч доков и в шапке iddoc у задублированных записей на новые значения iddoc этих записей из 1sjourn.

Ну удачи :)
А как ты узнаешь у какого дока id оригинальный, а у какого не тот? :)
возможно запись задублирована только в 1sjourn
   Ёпрст
 
82 - 07.11.20 - 21:55
Хотя проще в dat поменять, тогда оно само шапку и всё остальное нормально слепит..а так, еще и записи проводок/операций/регистров..нужно править, по идее и значения периодики, установленной документом
   trdm
 
83 - 07.11.20 - 21:56
(82) Вот именно.
   trdm
 
84 - 07.11.20 - 21:58
Но тут свои сложности, т.к. id-ы просто так не найти, т.к. у всех таблиц нумерация с 0 идет. И id справочника может совпасть с id документа.
   Ёпрст
 
85 - 07.11.20 - 22:27
(84) ну, в dat файлике достаточно всё прозрачно
   Ёпрст
 
86 - 07.11.20 - 22:28
кто-то даже конвертер писал, по переводу его в xml и обратно..
   Cthulhu
 
87 - 07.11.20 - 23:03
ну и толку то вы найдете iddoc-дубликаты и все iddoc-дубликаты поменяете... на мах(iddoc)+1 - дубликаты!
   Ёпрст
 
88 - 07.11.20 - 23:49
(87) ? как это дубликаты ? Ты всегда +1 прибавляй и не будет дублей..це же очевидно :)
   Cthulhu
 
89 - 07.11.20 - 23:55
(87): это в какой таблице? ну, давай, итак.
макс.ид=10 (ну допустим).
1. в 1sjourn - нашли, допустим, дубликат, два раза iddoc=2.один меняем на 11, второй на 12.
2. оба, допустим, документы одного вида. идем в dh - а там две двойки. какую из них менять на 11 какую на 12?.. ну, допустим, кинули монетку - угадали. дальше...
3. идем в dh - ойёоо, а там куча двоек. кикие из них менять на 11, какие на 12?..
4. ай, перекрестились - идем по другим тамлицам.. и какие из двоек менять на 11 а какие на 12???
   Cthulhu
 
90 - 07.11.20 - 23:57
(89)+: это я предположил, что ты в (88) ошибся, предлжив сплошняком по всем таблицам все двойки тупо потоком поменять на совершенно разные "всегда +1 прибавляй" - тогда б данные вообще тупо развалились бы..
   Ёпрст
 
91 - 07.11.20 - 23:59
(89) во всех вестимо..но проще в одном месте - в dat файлике :)
   Ёпрст
 
92 - 08.11.20 - 00:02
И..посмотреть сперва что за вид дока и нужен ли он вообще, чтоб этим морочится и делает ли он движуху и какой там closed стоит и какие флаги в регистрах.. ну и т.д
   Cthulhu
 
93 - 08.11.20 - 00:54
(91),(92): ты не ответил на (89). там по пунктам. можно вместо таблиц полагать секции дат-файла.
если тупо все по потоку двойки с автоинкрементом переназначить - то данные развалятся, как это отмечено в (90). иного спооба различить в разных местах - какую из двоек менять на 11 а какую на 12 (документ одного вида). и?
   Cthulhu
 
94 - 08.11.20 - 01:03
я уже не знаю как объяснять. ну на примере (89).
находим первую двойку 2-ку в строке, относящейся к таблице общего журнала, меняем на 11...
ищем дальше - находим двойку в строке, относящейся к таблице общего журнала, меняем на 12...
ищем дальше - находим двойку в строке, относящейся к строке dh-таблицы, меняем на 13 (и - опа, а такой строки в общем журнале нет. ну ладно. забили, поехали дальше...
ищем дальше - находим двойку в строке, относящейся к строке dt-таблицы , меняем на 14... и - опа, а ведь такого ид-а в сооответствующем dh нет - и эта строка табличной части относится к какому-то несуществующему документу которого и в журнале тоже нет...
идем дальше... нет. уже никто никуда не идет. бо данные раз.ва.ли.ва.ют.ся.
   youalex
 
95 - 08.11.20 - 06:32
(91) А в dat-файле ты сможешь понять, какая именно из строк дубля - условно правильная? Мне кажется, тут две задачи: 1) избежать ошибки уникальности, чтобы загрузка выполнилась штатно. 2) Анализ эти дублей, с целью  корректировки данных . B Скуль для п. 2 подходит как нельзя лучше.
Если же просто делать id+1 по top 1, то ситуация еще больше запутается, может получиться, например, что есть движения в rg по помеченному документу и т.п.
   AAA
 
96 - 08.11.20 - 06:50
1 - пишите, что базы нет, а куда она делась, удалили что ли ? Если есть, но не запускается из за большого файла, то можно и с ней поколдлвать
2 - если все таки базы нет, то я бы последовал  совету Епрст, отключил контроль уникальности, загрузил базу в sql, а там уже смотреть что дублируется
Может и менять ничtго не надо, просто лишнее удалить. Когда есть база, можно что то думать и решать, а когда нет, то можно долго обсуждать. но на одном
иесте. Выгрузка все равно уже устарела, надо будет базу догонять первичкой, ну также можно догнать и кривой день, когда случился дубль и база вылетела
Надо загрузить ))
   Duke1C
 
97 - 08.11.20 - 16:07
(94) Всё правильно.
Поэтому править лучше в DAT файле, там гораздо проще будет в данной ситуации
   Cthulhu
 
98 - 08.11.20 - 16:15
(97): кхм.. а там у меня в формлровках - про строи дат-файла. и про строки таблиц. т.е. и то и то - расползается. :/
   Duke1C
 
99 - 08.11.20 - 16:21
+ (97) Там у доков ID только в строке шапки записан, остальное - "экстраполируется" платформой при загрузке данных.
Если я правильно помню.
   Cthulhu
 
100 - 08.11.20 - 16:22
(99): уверен? а в периодике - тоже?
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.