Интересует возможность создания в БД новых документов путем прямой записи в таблицы оной БД. У кого-нибудь имеется подобный опыт? Нужно для ускорения формирования документов, в данном случае именно скорость их создания - очень важный момент.

Лицензионное соглашение это вроде как запрещает.

имхо создание новых документов как новых записей в БД - я думаю это не то место на котором можно сэкономить.
запись в бд - довольно быстрая вещь. медленное же - это те расчеты которые происходят при записи (например остатков). так что копайте здесь

(2) Ну не знаю... Понятно, что расчет остатков прямым запросом тоже ускорит дело, но про создание объектов последним могу точно сказать, что когда раньше переносил справочники стандартными способами (tranref, export\import, OLE, КД), то перенос занимал до полутора суток. После того, как преешл на прямую запись в таблицы БД, все справочники переносятся в течение 5 минут.

(3) Если не секрет - сколько в справочнике элементов, что он переносится 36 часов?
Даже по 10 элементов в секунду это 10х60х60х36=1,296,000 (мильён двести девяносто тысяч)
И это у тебя не разовая операция, а повседневная процедура?

(4) Кто сказал, что речь об ОДНОМ справочнике?

(3)ну справочник не документ ... в клюшках для справочника всего одна таблица ... с документами дело обстоит все гораздо сложнее ... даже если записывать без проводок их уже там две ...

(6) Мне и нужно просто ввести документы, не проводя их. Это будет только запись в _1SJourn, DT и DH.

Если не проводить документы, то они записываются быстро

(7) Ещё 1SCRDOC

(7)ну так если справочники переносил в чем проблема-то?

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

(11)там иды надо писать ... исключение для состовного типа ... в принципе таже хрень что и при записи справочников

(11) А какие препятствия к прямой записи ссылочных реквизитов?

(13) ну фиг знает... :-) для начала их (ссылки) еще получить надо

(9) В _1Scrdoc хранятся подчиненные документы, у меня таких не предусматривается.
(10) Справочники переносил из олдной базы в другую, а здесь нужно в текущей же базе создавать новые записи. Собственно, вопрос, по сути сводится к тому, как сгенерить значение IDDOC, и еще так, чтоб оно больше в журнале не повторялось.

(14) Эта проблема уже решена, так что прошу с ней здесь не заморачиваться.

(15) а как генерились ИД для справочников когда писал  напрямую?

(17) Читай внимательно: "справочники переносились из одной базы в другую"! Они не генерились.

(18) а ну да. а документы? почему нельзя также взять ид из другой базы?

как я понял проблема правильного формирования иддок это единственное что препятствует прямой записи

(19) Именно так.
Взять из другой базы ИД - мысля, конечно, оригинальная :) но боюсь, тоже не вариант, т.к. ИД из другой базы могут совпасть с ИД в текущей.

+(20) Правда, можно сделать в запросе соединение по условию "ГДЕ ИДДок_ТекБазы IS NULL"

+(21) но тогда опять же встает проблема, что в базе-источнике ИД-шек может не хватить :) ибо документов предполагается ввести до фига...

ид в клюшках это обычное число ... записаное 36-ричноей системе ... http://club.shelek.ru/viewart.php?id=132

Номер средствами самой 1С можно получить использую функцию _IdToStr() и наоборот получит десятичное число из его тридцати шестеричного представления  _StrToId().

(20) А если тупо искать максимальный и инкрементировать?

(22) Или заведомо хватит. Или полный П - поскольку размер IDDOC не увеличить.

(23) Это я уже понял, спасибо :) собственно, вопрос в том, как сгенерить уникальный ИД
(24) Как в запросе можно преобразовать 36-ричное число в 10 систему?

(25) А зачем в запросе? Узнай, сколько номеров надо будет, создай таблицу - и из неё черпай.

(26) По ходу, к такому варианту всё и идет. Нужно ведь еще сгенерить и обычные номера документов...

(27)кстати иды не всегда подряд свободны ... так что опять надо проверять

(28) Если найти максимальный - то дальше всё будет свободно.

(29)если максимальный будет - "ZZZZZ"

(30) IMHO, проще глянуть, какой он там максимальный. Если ZZZZZZ - тогда искать свободные IDDOCи, а если от максимума номеров под новые хватит - шагать от максимума.

(15) Там не только подчиненные документы хранятся...

(25) а какие проблемы? примеры функций валяются и на SQL.ru, и на 1спп

Что-то мне не верится, что ядро 1С будет искать свободные IDDOCи - это же верный путь к нарушению ссылочной целостности. Так что не надо искать проблемы там, где их быть не должно.

(32) Да, ещё там графы отборов необщих реквизитов документов. Но в данном случае это непринципиально.

(0)http://www.1cpp.ru/docum/icpp/html/ODBC.html#getnewid

И.. врят ли скорость будет больше, чем штатная запись в иб

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

(0) При желании и в космос можно полететь... Тебе для чего?

(37)+ и еще там перекрестные ссылки какие-то есть, структуры которой никто не знает. Короче проще штатно, целее будет.

(37) Почему никто ?!
Я делал.. и справочники и доки.

(39) перекрестные ссылки ?!
:))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

(41) Единственная таблица которая хз зачем. Нигде нормального описания не нашел, а теперь уже и не помню что вообще о ней читал, но вроде как имеет некоторое отношение.

(40) После этого первым делом ТиИ? ))

(42) какая таблица ?? 1scrdoc ? Или что ?

(38) Для массового ввода документов. Если бы не было так сильно нужно, то и не спрашивал бы.
(43) Эх, сударь... ограниченный вы человек, не в обиду вам будь сказано.

(39) структура известна, назначение известно....

+(45) Там все предельно ясно: заполняется таблица журнала+Таблица шапки+таблица ТЧ. В чем может быть проблема?

(44) она

(45) так у нас тут вообще "узкий круг ограниченных людей" :-)

(48) дык на:
http://www.script-coding.com/v77tables.html#1.2.3.

там вообще никчего сложного нет - родитель да предок для документов, для граф отборов тоже ничего сложного.

(45) Да просто записью в таблицы я как бэ баловался, только другой немного. Делал УРИБ из разных баз. Ну в смысле сначала тупо объединением делал их одинаковыми, а потом иды подгонял, чтобы они поверили что одна база. Усе получилось, но без ТиИ после такой записи помнится не обходилось. Какие-то служебные я не заполнял, а тупо сносил и при ТиИ они новые создавались.

(44) Раз уж вы здесь, то не подскажите по такой еще проблеме: вы тут мне подсказали в одной из последних веток, как упростить перенос данных между базами SQL. В-общем, всё получилось, теперь работает на ура. Но есть еще вопрос: в данном случае удобство использования одного запроса к обеим базам было в том, что перенос между базами осуществлялся как SQL --> SQL. А как быть, если обмен будет в виде DBF --> SQL? И еще: где можно почитать про аналогичный перенос данных на файловых базах (через фоксовый провайдер)?

(51) Мне после прямой записи в базу никакого ТИИ не требовалось.

(52) а какя разница ? синтаксис немного другой  при использовании oledb и поля немного отличаются в sql и dbf в части date_time_iddoc и раздельного date time  в dbf, ну и еще, по мелочи - типа вида дока и маркера удаленных записей\групп справочников

(36) Опа! Надо же, "как много нам открытий чудных..." :)
Почему скорость не будет выше?

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

(54) Про эти мелочи я знаю! Что в синтаксисе тоже отличия небольшие есть, тоже в курсе. Но если одна база файловая, а другая скуль, то как к ним обеим в одном запросе подцепиться?
(56) Других в базе в этот момент, кстати, не будет...

(57) через фоксовый провайдер

+58
+ присоединитьмд() ..на 1cpp есть примеры запросов+ использование метапарсера для второй базы, чтоб не ручками имена полей писать + синхронизация по коду..

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

(58) Т.е. использовать строку соединения вида
Соединение = "Provider = VFPOLEDB.1; Data Source = "+КаталогИБ()+"; Mode = ReadWrite; Collating Sequence = Machine";
?

(59) Можно глянуть, плиз?

http://zalil.ru/32179412

(62) Благодарствую

(0) Переходи на сап и не мучай 1С.

(64) Спасибо, подумаем :)

(0) Ну делал подобную хрень. И вопрос был не в скорости записи, а в гребаной 1С-ной блокировке таблицы документов (руки б повыдергивал идиотам которые сделали такую хрень). Т.е. когда сидит штук 8 операторов и фигачат документы, то этот затык просто выводил всех из себя.

Еще раз - это когда у тебя куча народу дергает документы на запись. В подавляющем большинстве случаев отсилы 2-3 человека тусуются с документами, остальные смотрят отчеты или справочники.

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

(3) Значит нужно было уволить прога который не мог допилить перенос, а пользовал в том виде. Хотя может он любитель садо-мазо ?..

не забудте про вероятность ввода двух документов
с одинаковым id

(66) В таком случае можно сгенерить в журнале в одной блокировке кучу записей. А уже после - добавлять и заполнять Ш+ТЧ+ссылки, там блокировка не нужна.