Проблема дубля и удаления записей из .DBF таблицы

[Дулин]

Вы уверены, что хотите этим заниматься сами ?

Может вам лучше грамотного спеца вызвать ...[/QUOTE]


Уверен...

[Дулин]

Хорошо. Кого же обозвать грамотным специалистом? Пока никто на вопрос (в реале, не на форуме) мне не ответил. Я по этой теме уже много с кем беседовал, тоже вроде бы опытные грамотные программеры. Руками все разводят....

[Дулин]

Я 1с вроде злобной и кривой не называл. В каждом ПО есть свои прибамбасы. Но пока 1С не справляется. Не обеспечивает надежности храниения инфы.. Считаю - что 1с не есть хорошее ПО по сравнению с тем же Фоксом (не говорю о чистой бухгалтерии). Просто писать прогу по учету платежей за газ с населением - бредовая идея. Она глючит уже с объемом в 30 тыс контрагентов. Не говоря о том, что придется "впихнуть в нее" все 170... Но начальство непоколебимо...

[Дулин]

Справочник не подчинен. Коды строк все уникальные.

[Дулин]

Рассказываю....
Получил я 6 таблиц формата .dbf
1 - Abon.dbf -справочник контрагентов. все коды уникальные.
все остальные таблицы - подчинены 1-ой, ну грубо говоря это их сальдовки, и прочее.
Загрузил эти таблицы в 1ску. что еще то сказать?
База под SQL - без проблем, никаких дублей нет и не будет.
.dbf базы - периодически выплевывает дубли. т.есть исчезает одна запись и вместо нее появляется другая, уже существующая, строки полностью идентичны.
Несколько раз делал проверку баз средствами 1с. она чего-то делает, говорит все хорошо....
о как

[Дулин]

Исходные таблицы получил с помощью FoxPro 3.0
ПРоверил их на уникльность.
Загрузку в 1с - писал сам. Обработка загружает эти таблицы в справочники. Проверил средствами 1с на наличие ошибок, ошибок нет. Все коды контрагентов в справочнике уникальные.

Как узнаю о пропаже строки? - не идут остатки на начало периода.
Открываю соответствующую таблицу (посмотрел в .dd файле) и вижу , что нарушена последовательность кодов. например, 1,2,3,4,718(а),6,7.....717,718(б),720... строки 718(а) и 718(б) - полностью одинаковы, ПОЛНОСТЬЮ. а строки с кодом 5 нет совсем. А иногда он 718 строку просто вместо 5 вставляет (тоесть 718 строк становится на место 5, без дубля).
Одна база висит по SQL-здесь этого не наблюдается, а еще 3 базы в dbf формате - вот здесь все и происходит.
Я не один смотрел и искал проблемы, еще спецов приглашал, мы не нашли причину.
Все, кто работает в базе не могут сказать какие действия со справочником они предпринимали, нет последовательности действий, после чего возникает такая ситуация, поэтому не могу отловить глюк в коде программы.

[ValeraH]

"иногда он 718 строку просто вместо 5 вставляет"
Вообще-то 1С с dbf так работает, что, если вы удалили элемент справочника под № 5, то в файле он не удаляется а помечается на удаление, а потом вводите новый (718), он дописывается не в конец файла, а вместо помеченного на удаление (например 5).

[Дулин]

Нет, я выгружал средствами FoxPro 3.0 из таблиц .dbf
Потом полученные dbf таблицы загрузил в 1с-ку.

Кстати, ValeraH, а если помеченных на удаление нет? Я таблицы упаковал.

Aquad, да строки одинаковы полностью. поля parent ID нет, есть поле ID оно тоже одинаковое.

[Дулин]

еще кстати, если он пишет новую строку вместо помеченной на удаление, то почему он копирует уже существующую. ведь 718 - он уже есть, он не новый вовсе

[Дулин]

Вот структура файла... я не вижу поля parent id

#===============================================================================
#==TABLE no 8 : Справочник абонент
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=SC902 |Справочник абонент |A |SC902 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=ID |ID object |C |9 |0
F=CODE |object code |C |5 |0
F=DESCR |object description |C |100 |0
F=ISMARK |Flag Object is Marke|C |1 |0
F=VERSTAMP |Version stamp |C |6 |0
F=SP1399 |(P)АрхивныйНомер |C |20 |0
F=SP1049 |(P)ГВС |C |9 |0
F=SP1572 |(P)ДатаДог |D |8 |0
F=SP1643 |(P)ДатаРегистрации |D |8 |0
F=SP929 |(P)дом |N |5 |0
F=SP930 |(P)квартира |N |5 |0
F=SP1549 |(P)контролер |C |9 |0
F=SP1627 |(P)ЛитераДом |C |4 |0
F=SP1628 |(P)ЛитераКвартира |C |4 |0
F=SP1370 |(P)ЛицевойСчет |C |20 |0
F=SP1334 |(P)НаселенныйПункт |C |9 |0
F=SP1571 |(P)НомерДог |C |20 |0
F=SP1406 |(P)СтарыйНомер |C |20 |0
F=SP906 |(P)Счетчик |C |9 |0
F=SP2377 |(P)Тел |C |8 |0
F=SP1327 |(P)Территория |C |9 |0
F=SP916 |(P)улица |C |9 |0
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDD |of ID |0 |ID |IDD
I=CODE |of CODE |0 |CODE(UPPER) |CODE
I=DESCR |of DESCR |0 |DESCR(UPPER) |DESCR
I=VI1049 |VI1049 |0 |SP1049,DESCR(UPPER) |VI1049
I=VI1549 |VI1549 |0 |SP1549,DESCR(UPPER) |VI1549
I=VI1370 |VI1370 |0 |SP1370(UPPER=128),DESCR(UPPER) |VI1370
I=VI1334 |VI1334 |0 |SP1334,DESCR(UPPER) |VI1334
I=VI1406 |VI1406 |0 |SP1406(UPPER=128),DESCR(UPPER) |VI1406
I=VI906 |VI906 |0 |SP906,DESCR(UPPER) |VI906
I=VI1327 |VI1327 |0 |SP1327,DESCR(UPPER) |VI1327
I=VI916 |VI916 |0 |SP916,DESCR(UPPER) |VI916

[Дулин]

.. да, загружал 1с обработкой.

[Дулин]

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

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

Я ведь уже писал, что конфигурация написана полностью руками.
Файл (таблица) - в одной базе 3000 строк, в другой - 5000, еще в одной 7000.
Главное, что я не могу выявить действий, после чего возникают такие строки. Есть подозрения, что это результат отработки тразакций....

[Дулин]

Разрешите ссылочку оставаить. тут человек грамотнее разъяснил суть проблемы..

http://itland.ru/forum/index.php?showtopic=4878