Ограничение на кол-во строк в документе, для dbf и sql версий #457658

в базе есть документы за 60000 строк в сиквельном варианте работает нормально, если закрыть глаза на номера строк)) получится ли её перегрузить в ДБФ, с её 4 разрядами на номер строки?

..и ежели всётке выгрузка загрузится, нормально ли они будут проводиться?

А сам как думаешь, если поле не более 9999 )))

я думаю, что есть варианты..) просто щас под рукой подходящей базы нет проверить..

Нет вариантов. Нельзя отобразить и нельзя построить основной индекс I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO

ичто?.. невижу связи.. уникальность индекса стоит в "0"

Когда 1С работает с документом она порциями извлекает данные из таблицы по индексу. + Уникальнось в файловой на уровне логики.

- гадкий мальчишка!(с)  (голосом Фрекен Бокк) )))

а ты попробуй :) и нам расскажешь

вот щас и пробую)).. пока только 1800 строк сформировалось... меня вот только логика работы sql сервера удручает.. база 2.5 гига, памяти под sqlsrvr.exe занято почти столькоже, выходит большая часть закеширована..  почему лампочка на диске непристанно мигает?

чото я тупанул! )))..  инсерт же происходит )))))

ёпрст.. это мне до второго пришествия ждать...  только 3000 строк сформировано

Прямой запрос 3000 элементов записывает за пару сек. Видимо 60 000 в единой транзакции - надо было по порциям по 200-500

мне лень чото писать.. я тупо, в документе, кнопочку "заполнить" нажал.. а там на каждую доб. строку происходит запрос!... ааа ))))

....почему лампочка на диске непристанно мигает?.... Ваще нимагу. Думал я - пьян.

Ничего страшного, если нет привязки к номеру строки в движении. Плюс при открытии "тупить" будет, т.е. долго открывать. Но работать будет, и данные не потеряются Да, и еще при ТиИ он будет ругаться на этот документ, типа неправильный номер строки

угу.. щас загрузил, всё работает!.. просто строки, которым не хватило номеров, получили номер "0", соответственно порядок строк в документе поменялся

--- можно, конечно, больше, но ТиИ матерится и нумерация слетает так шта про 60 000 в скуле ты слегка ошибся

Бедный клиент

я не ошибся, строк действительно более 60000.. нумерация в sql выглядит так: от -32768 до 32767

не очень понятно про бедных клиентов.. но в любом случае бедность это плохо

я про "в сиквельном варианте работает нормально" ты ТиИ запусти  ))

всё нормально, не переживай! ))

при чем тут переживания? ты вводишь народ в заблуждение

..ну, во первых, не стоит верить всему, что пишут а_фторы на форумах! )))) а во вторых я никого в заблуждение не ввожу.. мяхка говоря))

вам только камни на солнцепеке колоть! ))) сейчас специально, думал мож чо пропустил, запустил ТиИ.. ругнулось только на: "Неразрешенная ссылка. Создан новый элемент. Справочник Сотрудники. Код Шпакова" никаких косяков с документами тии не выявило! у меня таких 8 баз и некоторые работают уже по 8 лет..

проверять щас не буду, возможно начинает материться свыше 65ххх строк

Уже было. Года два назад писали, что нормально док работает. Только номеров строк нет. Да и у меня кажется есть подобные доки. Акт инвентаризации - седня нач склада говорил, что там в последнем 29 тыс. позиций.

получится. Ограничение ДБФа - 100к строк

Сам проверял? 100к - это десятичная система.

Именно столько, формат хранения того номера покури...

И от чего у меня никогда не падает, наверное руки неоттуда растут...

загляни в ДБФ

Ровно четыре девятки предел. ТиИ ругается, но не роняет. Я просто одноэсить с оператора начинал в пупермаркете, когда я типа програмлю а товаровед за мну наклыдные забивает, но это не суть.. Суть в том что в пупермаркетах есть такой док как ОтчетККМ который как правило больше 10000 строк, и как ся ведет эска на таких объемах я довольно-таки неплохо изучил. Как резюме - ничего страшного, если нет объема, но формат хранения именно двлично-десятичный, впрочем как и в любом дбф...

двлично-десятичный = двоично-десятичный

хотя нонешняя молодежь наверное и не в курсе что это такое...

и т.д.