Есть ЗУП, на SQL, в нем есть такая операция как отражение в рег. учете. Код мы там чуток подправили и вставили чтобы при заполнении в регистры писалось порциями по 50 000 записей. Всё это работало.
Затем в июле начали вести детальные наряды, за счет этого количество записей которые делают наряды в регистр расчетов Отражение основных начислений в бухучете сотрудников организаций увеличилось с 20 тысяч, до 300 тысяч. Когда стали формировать отражение, то запись каждой порции в регистре увеличилась с 6 минут до 40-60. И через некоторое время падало с ошибкой о нехватке памяти. Изменили размер порции до 1000, перестало падать, но скорость не изменилась. При этом скорость записи не постоянна, прыгает. Замеры показали что основное время идет на команде записи в регистр. Перенесли в файловую базу, там всё нормально просчитывается.
Позвали специалиста из франчи, за 2 дня работы он выдал ответ: из-за того что у нас в в регистре увеличилось количество записей запись в регистр идет долго.
Насколько может влиять объем данных на скорость записи в базу у 1С? получается что у 1С ограничения на объем данных?
ОС и сервер приложения 64х-разрядные, оперативки на сервере 32, запускали в терминале на том же сервере.

База скл вообще обслуживается?

сначала нет, потом провели все что требует 1С и другие, результат 0 (переиндексация, чистка кэша запросов и т.д.)
Хотя переиндексация давала непродолжительный прирост быстродействия.

(0)[получается что у 1С ограничения на объем данных?]
у 1С нет ограничений, а вот писать одним документом миллион проводок сервер с жалкой памятью в 32 Гбайт не сможет

чистка "кэша запросов" после обновления статистики токмо и полезна...
Точно целиком дольше пишет, чем порциями?

можно писать в фоновых ещё, паралельно. много от чего зависит

(0) Проблема только с этой базой на данном сервере? И какого объема база?

(0)>>Затем в июле начали вести детальные наряды
давайте, давайте вести с полей, а то народ совсем забыл о реальности с 1С.
(1)>>База скл вообще обслуживается
это не поможет. Это - не проблема SQL.
(3)>>у 1С нет ограничений
есть. В том числе и системно-аппаратные, как и у Виндовс.
Но самое главное ограничение - невозможность обрабатывать большие объемы записей.
более 100-200 тыс записей в выборку - и 1С можно выкидывать.
Про полмиллиона говорить вообще бессмысленно.
Но у вас миллиард .... лежит мертвым грузом. А производительность измеряется именно в этих единицах, указанных ТС.
(5)>>можно писать в фоновых ещё
бессмысленно. Не поможет.
(6)>>Проблема только с этой базой на данном сервере?
проблема со всеми базами и у всех, где люди работают, и идет мало-мальская обработка данных.

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

(3) это не проводки, а регистр расчетов и их не миллион, а всего 100 тысяч.
(6) только с этой, объем базы где-то 25 гигов на скуле, в файловой 13 гигов.

(7) всё нормально с 1с, несколько миллионов проводок одним докуметом - это ещё несколько лет назад нормально на 8.1 прокатывало, надо уметь готовить просто, сплошные "не поможет" и "1с авно" у Вас товарищ

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

(7) в УПП у меня выборки миллионами записей идут, проблем нет.

(10)>> это ещё несколько лет назад нормально на 8.1 прокатывало
прокатывало? ))
ну-ну. видно и сейчас "прокатывает", пока реально база не вырастет или не понадобится действительный анализ, а не фиктивный перебор або-каких данных.

(9) я почему спросил - просто у меня когда пытался немаленькие базы (ну больше 10 Г) в файловый режим вернуть - у меня всегда ошибку выдавало " Не все данные загружены" (ну что-то типа такого)...

(13) в УПП расчет себестоимости легко за миллион проводок сделать может.

(7) Прочитал - и жить не хочется :)

(12)>. в УПП у меня выборки миллионами записей идут
это вам 1совые тесты показывают?
100-200 тыс для 1с сервера. И то при всех оптимизациях и настройках.

(14) в файловой ограничение на размер одной таблицы, когда выходит за пределы тогда вылетает.

(16) не читай ерунду, данный товарищ известен своей ненавистью к платформе 1с, и не приемлет доводов что она действительно работает не только с ларьками, а с крупными холдингами

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

(20) это значит что там был не специалист

(21) всё свелось к следующему: "при записи возрастает нагрузка на процессор (по замерам системы), значит что-то там в sql делается, а что не понятно. Это скорее всего из-за того что предыдущие записи как-то обрабатываются."

(22) :) см (21)

поток сознания какой-то

(24)    -Видишь суслика?
        -НЕт
        -И я не вижу... а он есть....

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

(0) postgresql?

(26) анализ проблем - не простой вопрос, и нет точных инструкций. на вскидку:
1. Средстами 1с - замер производительности (на сервере тоже конечно). так поймёшь где именно тормозит, на Строк Набор.записать() скорей всего, но кто знает.
Если включено РЛС - естественно делай под полными павами, без РЛС.
2. средствами винды - счетчик на дисковую систему, память. смотри очереди и т.д.
На скуле посмотреть сколько памяти выделено ему. Предварительно реиндексация, обновить статистику, сбросить процедурный кэш... Всё это в джоб скуля, каждый день.
Это в общих чертах, чтобы хоть определить узкое место

(26) модель восстановления простая?
Попробуй сделать реструктуризацию в ТиИ.
Попробуй настроить сервер:
http://infostart.ru/public/65955/
У Гилева кое-какие есть рекомендации, поищи.
Найти узкое место - проц, память или диски, тем более пишешь что сервера менялись.

(26) Больше всего меня смущает приемлемая скорость работы в файловой базе... Вроде как напрашивается подозрение на супернеоптимомальные настройки SQL... В идеале хорошо б проверить скорость на другом физическом сервере, возможно на другой СУБД

(30) Я за то, что у автора стоит PostgreSQL и он об этом умалчивает.

(29)+ антивирус долой если стоит. Если 1c и sql на разных серверах, то попробовать поставить на один.
Если 18 релиз платформы, то попробовать через подключение native client. Проверить не распухает ли tempdb. Хватает ли памяти на дисках во время проведения. Нет ли ограничений на файлы подкачки. итд
Искал недавно причину падения рабочих процессов с ошибкой 10054, чего только из этого не перепробовал. А оказалось банально что циска на одном из сегментов глючит.

(28) это всё делали
(27)(31) MSSQL 2008

(29) Простая, реструктуризацию делали.
(30) пробовали, но так как сервак разворачивали те же самые админы, то у меня нет уверености в оптимальности настроек

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

(35) скуль на записи проц отжирает. Дальше не знают как анализировать.

проц очень редко узкое место, диски и память намного чаще. Если бы конкретно на каждый пункт из (28) ответил - можно подумать бы было ещё... а так - я хз что вы сделали реально

можешь еще показать чего-там наваял с порциями. кстати а если к типовой вернуть как?

(19)>>а с крупными холдингами
у всех остальных товарищей даже в крупных холдингах - 1С чисто побаловаться.

(20)>>а это значит вывод что влияние размера базы влияет на запись построен только на предположениях.
я прекрасно осведомлен, кто пишет о "1С обрабатывает гигансткие объемы", и каких специалистов вызывают при этом.
То, что никаких "миллионов" в одной транзакции нет и в помине - мне прекрасно известно, также, как и тех небылицах, которые "одинэсники" рассказывают друг другу.

(19)>>известен своей ненавистью к платформе 1с
ну вам-то никто не мешает признаваться в любви друг другу.

(41) Привет.

(42) привет

(34)хотя, с другой стороны, где еще можно похвалиться размерами слонов, которых не видел, и убеждать про миллионы записей на поделке без собственной СУБД, сделанной студентами между сессиями на коленке, и купленной директором вместо коньяка.

(42) как дела в москве?

(45) Отлично.
А я вот смотрю - вы вернулись с новыми силами пургу нести?

(39) То, что 1С местами довольно корява, с вами никто не спорит - но как объяснить, что у автора проц начинает "озадачивать" именно MSSQL ?

(47) конечно, если отмести варианты на уровне базы включено шифрование или сжатие

(10)Ну дык поделись рецептом!

(28) 1. Зависает имено на записать(). РЛС не используется
2. счетчики включили смотрели, винты в норме, только на проц нагрузка идет. Скулю выделено 12. "Предварительно реиндексация, обновить статистику, сбросить процедурный кэш" - делали, не помогает

а (38) не?

присоединюсь кстати к (38), чего с порциями наваяли? и как?
остальное подумать ещё надо

ЗУП кстати какая? Блокировки Автоматические?

Раз всё так, как сказано в (50) - надо копать в сторону скуля уже. Запустиь профайлер и глядеть что такое он там делает

(38) счетчик поставили на подсчет количества записей в наборе и дополнительно НаборЗаписей.Записать(Ложь). Поставили потому что если одним куском записывать, то вылетало по нехватке памяти.
(53) ЗУП 2.5.61.1, блокировки управляемые
я и склоняюсь к тому что где-то в скуле проблема, только ткнуть своих "спецов" нужно, они теперь ссылаются на мнение стороннего специалиста

300 тысяч - не много на самом деле...
Тут ещё нюанс правда - регистр Расчета это, своя специфика. Например если записи с периодом действия - при записи каждой порции у тебя всё пересчитывается каждый раз, и могут меняться уже существующие записи. Вычисляется фактический период действия

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

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

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

У этого регистра нет вытеснений, это самый простой регистр расчетов.

(54) уверены, что обрабатывали именно регистры расчета?
типовой пробовали?
раз пришлось закоментировать РегистрацияОбъектовДоступаДокумента

(58) так и стоит: порции собираются по людям

(60) по замерам на какой команде записает смотрели.

*зависает

(63) там порциями у вас, на каждой порции тупит?

(65) да, но в одной порции несколько человек вмещается.

Записать(<Замещать>, <ТолькоЗапись>, <ЗаписьФактическогоПериодаДействия>, <ЗаписьПерерасчетов>).

Можно попробовать без записи фактического периода

Записать(, Истина);

(67) попробуем

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

(68) в принципе помогло, только Записать(,,Истина)

для эксперимент убрали с проведения все наряды за месяц, регистр очистился - скорость не добавилась.

(10) лапшу 1совую не вешаем.
Если в "поле" не работаем. а только "по слухам", которые распускают такие же неработающие - то не пишите, чего не знаете.
Тест:
запись миллионов элементов справочника (типового, заметьте! нетиповой весомый вообще не осилила) - 500 000 за 18 часов.
1С сервер и SQL.
Если б была "прямая связь" - SQL бы сделал эту работу минут за 5 максимум.

(73) я вам доказывать ничего не собираюсь, а работаю как раз в "поле", 2 проекта в крупных холдингах, и РСВ с 1,5-2 милионами проводок делалась не сутками, а за рабочий день.
Хреновый у вас тест и всё остальное. Автоматизируйте ларьки

у нас РСВ с 1 лямом проводок(500 тыщ БУ и 500 тыщ НУ) делается за 4 часа

(0) "При этом скорость записи не постоянна, прыгает"
может у Вас на сервере какие тяжелые регламентные операции выполняются в это время? Или какие запланированные задания (не 1с-ные)?

+ (76) кстати (72) вроде как раз в тему будет

А профайлер смотреть пробовали ?

(0) мои предложения - гадание на кофейной куще, но может что-то поможет:
1) выполнять код записи регистра на сервере
2) увеличить файл подкачки на сервере и в SQL
3) нормально ли закрываются регистры?. Провести ТиИ
4) пробывать записать в режиме обмена данными - может идут перед записью хитрые проверки
5) как-то изолировать регистр (чтобы к нему другие не могли обратиться)

а, опшипся немного.
Ситуация такая: завис 1С-сервер, вот и посчитал сначала, что 18 часов.
По логам - вылетел через 7 часов после начала теста.
Итого - 500 тыс записей и 7 часов.

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

(74)>>Хреновый у вас тест и всё остальное
одноэсники всегда ругают 1С, но даже не подозревают об этом.
Но когда назовешь конкретно причину - все, начинается война.
Тест - всего лишь запись элементов справочников. Чисто порсмотреть, за какое время произойдет запись.

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

(0)Нормально 1С8 с такими объемами работает. Не слушайте никого. А то что оптимизировать нужно уметь - так это на любой системе необходимо.

(84) ну да.
Убеждался десятки раз - как "нормально".
(74)>>РСВ с 1,5-2 милионами проводок делалась не сутками
вы отличаете ЗАПИСЬ миллиона записей и обработку? Если запросы более-менее оптимизированы "по кускам" - то обработает. И чем быстрее проц и все остальные системы - то обработает быстрее.
ЗАПИСЬ же миллиона элементов - идет в 1С где-то часов 20. И это при условии, что ничего и нигде не вылетит по пути.

(84) +1
необходимое для ERP систем производительность 1С обеспечивает

любителям же построения на 1С OLAP-ов и  биллингов срочно к психиатру

(85) При чем тут обработка? РСВ считает + ЗАПИСЫВАЕТ эти 1,5-2 милиона, причем не в справочник, а в жуткий РБ. Или запись в этот регистр не считается?

+ "по кускам" - имеется ввиду наиболее эффективная "оптимизация" запросов в 1С: рабивка объемов данных при запросе на более мелкие части.
Все остальные "оптимизации" на больших объемах - фикция. Ну разве что кардинальная перестройка результата дает больший эффект (это когда не "в лоб" обрабатываются огромные объемы, а сначала делается анализ - а что реально нужно в результате. И куча данных отпадает сама собой).
А если нужно "перелопачивание" промышленных данных - 1С пас.

(87) вот именно чистая запись и идет с огромными проблемами.
И только у вас - таких проблем нет. И даже свежая тема в нынешнем месяце, где Записать() элемент идет часами - вам не указ )))

недавно тут тема была, чувак жаловался что в регистре ГрафикиРаботПоВидамВремени у него 4 млн записей, и решил чистить, мол тормозит. У меня в базе их 85 милионов, всё работет, зарплата считается. И объёмы и такие количества - ничего страшного для 1с, надо правильно к этому подходить, оптимизировать

(89) Проблемы есть всегда, но они решаемы почти всегда.
Проект внедрения Сухого закончился в этом году, при расчете зарплаты там 30 млн записей создаётся. Справились же, сам видел. Переписали конечно типовую в хлам, но всё можно сделать. там оракл конечно, не скуль

(90)>>У меня в базе их 85 милионов
я очень рад за вас, но "мертвые" 85 млн - это не то же самое, что миллион в памяти при обработке. А запись - там вообще туши свет, сколько всего лишнего делает 1с-сервер.
SQL миллион пишет за 20 минут. Да что говорить - пробовал в Excel - пишет миллион строк за 40 минут на офисной машине.

(91)>>Переписали конечно типовую в хлам, но всё можно сделать. там оракл конечно, не скуль
еще скажите, что они с 1С работают ))))
(Сухой, я имею ввиду)

(93) )) 1с УПП 1.3 если что, т.е. даже этому не веришь? Мне надоело доказывать что лично Вы не умеете делать или не хотите признавать, что есть нормальные крупные промышленные системы на 1с.

Желаю Вам лично попасть на нормальный большой проект в качестве обычного падавана, где будет вменяемый руководитель и архитектор.

(94) было бы здорово на таком проекте поучиться работать. Опыт будет бесценный. Только надо суметь его найти и попасть туда

(93) Сектант штоль?

(93) И очень много. Если интересно могу ссылку скинуть о проектах на 1С.

Раньше 1Сники мерялись письками мерялись, а теперь количеством записей в базе ;)

(94)>>в качестве обычного падавана
спасибо, уже учавствовал - и в больших, и в маленьких. Везде - при запуске (если не сам от и до делал) обещают одно, а потом, когда встает колом - "вы не соблюдали..." и список невыполненных требований на страницу. И много доков, и работали больше и чаще, и считали слишком много и часто и т.д....
И падаваном уже не солидно как-то - хоть бы предложили зам РП, на крайняк ))
А то - падаваном...

(98) ну так раз у народа только количество записей растет... да и то не знают, откель и что с ними делать ))))

(95)>>Опыт будет бесценный
навряд ли. Просто узнаете нравы больших корпораций, побудете винтиком, прочувствуете это, ну и, базу увидите БОЛЬШУЮ.
А так - везде одно и то же: когда приперает с производительностью - либо кластеры забабахивают на каких-нить блэйдах (экстенсивный путь) и ждут следующего часа "Ч", либо переделывают все так, что и 1С родная не узнает (интенсивный путь).

*припирает

(50) [Скулю выделено 12]
а не маловато будет?

(97) Мне кинь. И ещё, интересует литература по администрированию MS SQL. Что порекомендуешь? Окромя MSDN

(104)>>Мне кинь. И ещё, интересует литература по администрированию MS SQL
- ладно хоть вы не советовали в падаваны. А то и так ужо смешно от ваших товарищей )))
Ссылок на проекты 1С - полно на офсайте. Да только о реализации и реальной работе вы ничего не узнаете.

(105) а не смейся, я привёл реальный факт - призводственное подразделение Сухого в комсомольске-на-амуре на 1с УПП 1.3 + Оракл. Знаю кто внедрял, видел конфу, знаю что работает. Вы же упорствуете в своёй ненависти к 1с, видимо ничего путного у вас лично на 1с не получалось, иначе объяснить такое нечем просто

Вот еще интересный факт: на каждые 100 тыс 1С "думает" на 0,002 сек дольше над каждой записью.
В среднем.

известен также Камаз, но там я не вкурсе как работает и работает ли вобще

(108) да уж, про Камаз я наслышан. И про распилы и обещания там же. И как все продолжает работать на старой дельфийской программе и оракле.
Наверное, на Сухом аналогично )))

(105)
> ладно хоть вы не советовали в падаваны

Бисер жалко.

Зарплата на SQL всегда отличалась веселухой :)
Если не хотите сидеть на файловой - надо переписывать

(109) на сухом работают в 1с, 146%

(0) Рассказываю свой опыт с нашими сервисами (у нас в некоторых таблицах миллиард строк).
Раздувание таблиц - это постоянная покупка все больше и больше жестких дисков. (Капитан Очевидность :) )! Рано или поздно где-то что-то закончится - кэш на контроллере, способность процессора переварить объем данных от дискового массива, емкость дискового массива - не важно, важно что то где то всплывет аппаратное место, которое обозначит предел.
Вообщем то, да, можно отдавать на откуп субд SELECT к этим миллиардам строк, но вы же знаете как платформа может "неосторожно" спросить скуль с каким-будь LIKE. Это будет читаться террабайт. Вы когда нибудь копировали террабайт? Намного ли быстрее думаете будет SELECT? ). Имхо вот ЗУПе на больших объемах не надо ждать "типовая 1с = быстрая 1с". Большие объемы - это всегда НЕ ТИПОВОЕ. Что делать - ...переписывать! Размазывайте эти объемы по нескольким таблицам, еще лучше по нескольким базам. Нет желания думать,  заплатите нам, мы подумаем за вас )))

(110)и много бисера? Или там и не бисер вовсе, а так, пластик?? )))

(113) >>Размазывайте эти объемы по нескольким таблицам, еще лучше по нескольким базам
( 88)

(114) Вас сколько не корми, всё по форумам ходите.

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

(106) одно дело видел, другое дело костыли рисовал. Я тоже видел 7-ную конфу в которой работали 250 пользователей и она летала. Правда от 1С там только формы, все остальное - прямые запросы к скулю на чтения и запись. Но это же не значит что любая типовая на 7-ка будет летать на скуле. Не так ли?

(117) Это оборотная сторона достоинств.

(113) "но вы же знаете как платформа может "неосторожно" спросить скуль с каким-будь LIKE."

Я не знаю.
Расскажи, когда там платформа LIKE делает.

(116) да уж, если только такие у 1Са защитники остались... Значит, недолго 1Су вольница творить-без-разницы-что-вовротить )))

(121) У вас со зрением проблемы. Я не являюсь защитником 1С.

(119) Еще скажи "задел на 1С 8.5", в которой уж точно все будет ОК.

(106)>>на 1с не получалось, иначе объяснить такое нечем просто
ну так объясните, почему у 1С ничего не получается, а она упорно делает то же самое, и даже не ругается при этом на себя?! А ведь "ничего путного" ЛИЧНО у 1С так и не получилось.

(122) ругаете почем зря?

(123) Не скажу. Это недостаток. Что будет и когда будет - не загадываю.

(120) в динамических списках при "быстром" подборе например

(125) Ещё варианты есть? Или у вас всё сугубо дискретно?

(127) Ну да. В принципе - да.

(128) Мыш , вы были на Мистафесте?

(130) Нет, и не пойду. Был на партнерском один раз.

(120) ну вот у меня спросила, SQL подзавис, дал отлуп, сам работает, а 1С-севрер...
Это нечто.
Он вроде бы и работает (ну ладно, зависла сессия, которой SQL дал отлуп), так 1С-сервер ПОДВЕСИЛ и соседнюю сессию, которая никакого отношения не имела к зависшей. Разве что обе работали на одном SQL.
Я уж не говорю, что для 1С-а такой "отлуп" вообще никак не зафиксировался - по базе "все ок", и не важно, что при создании записей в базе все повисло напрочь...

+(131) Но с вами лично мы знакомы, да.

(130) да-да, объединитесь для поддержки друг друга ))
Это только мы, реалисты, по-одиночке тут хаим "зазря" 1С.
А вы всем скопом ходИте, из темы в тему )))

(133) Когда это?

(128) у меня сугубо для каждого )

(134) Вы слишком оптимистично присвоили себе звание реалиста.
(135) Примерно год назад, место не помню.
(136) Да вы талант. Что же забыли на ниве автоматизации?

(Odavid) Я не являюсь фанатом и сторонником 1С систем. Она всего лишь одна из многих. Не собираюсь ее не хвалить не ругать. Но отзывы я мог бы привести реальные(референса откровенно на вас было бы жалко).  Какая то у вас критика однобокая.

(138) Фанатикам (с любой стороны) ничего не объяснишь. Можно притащить осла к воде, но пить не заставишь.

(137) "Примерно год назад, место не помню. "

Пивная по концу света, вы рядом с Другой сидели, нет?

(138)>>Но отзывы я мог бы привести реальные
отзывы у меня и свои есть. А что одна часть программистов привыкла верить всему, что говорят (меньшая в 1С, потому как еще не работали с 1С толком), а другая - давно не хочет ни думать, ни работать (подавляющее в 1С), мне тоже прекрасно известно.

(141) Откуда ты пришел в 1С?

(139) ну так вы уже фанатик 1С. Даже если еще этого не поняли. Эти технологии оправдания всего, что угодно и в нужную сторону, уже давно продуманы и успешно работают у 1С.

(142) с Ворда. Сидел, документы набирал, а тут - 1С. Посидел месяц, попрограмил - понял, что есть что поругать.
И вот ругаю, ругаю )))

(144) А ты юморист.

Да, забейте вы ругаться!)) ЗУП 3.0 рабочая сегодня вышла. Все не так уж и плохо у 1С.

(146) Т.е. типа стартует чиста канкретна?

(146) ну так и сидела бы 1С на БП. Ну, пусть еще и ЗУП. Никто бы слова не сказал. Даже я ))
А вот уже столько лет не могу не молчать на все новые и новые фокусы и ловкость рук.

какие проблемы?

(140) Не помню.
(142) Из лесозаготовок.

(150) "Из лесозаготовок."

Поздравляю. На нашем форуме прижился новый Гений1С. Существо дикое, но забавное и безвредное.

(143) Где вы увидели оправдание мной 1С?

(151) Это про кого?

(0)"за 2 дня работы он выдал ответ: из-за того что у нас в в регистре увеличилось количество записей запись в регистр идет долго"

"за 2 дня работы" LOL, а что так быстро? настоящие специалисты полгода только предпроектное могут делать

(113)нет. 1с всё правильно пишет. это ваши кривые дописки валят сервер. учитесь писать запросы.

(0)ты решил проблему?

(149) легкая пехота подоспела? Кавалерия уже здесь ))

(0)прочту всю ветку как будет время - доставляет с первого сабжа "до 300 тысяч" так же как советы специалистов далее )))

(0) а кто ваc просил столько сотрудников в один документ пихать что потом даже 50 000 это только порция?

наверное того на ком стояло всё это слили а в руках блатарей любая техника металлолом

ЗУП - изначально кривая система, вытесняющие регистры расчета которые чегото там вытесняют в старых периодах это нонсенс - это никому не нужное русское ноухау.
поставьте туда хоть оракл хоть терадату, будет колосс на глиняных ножках.

Что-то не пойму я... Если в документ не влезает технологически более 10 000 строк, то 300 000 записей - это 30 записей на сотрудника что ли? Не кисло.

А я вот что-то торможу и стесняюсь спросить "Зачем из ЗУПа выгружать 300 тысяч проводок?" :( боюсь пошлют ларьками программировать :)

Зачем в бухгалтерии такая подробная деталировка проводок? Только не говорите мне что это нужно для ведения бух.учета - не поверю. Имхо, данные можно в ЗУПе консолидировать и далее сводно (например, без деталировки по сотрудникам) отправлять.

(162) Выгрузка в УПП, там эта детализация нужна. Да и дело не в выгрузке - отражение в регл. учете - это стандартная процедура в ЗУП.
PS. Ничего вы тут нафлудили

(161) 30 записей на сотрудника эта разве много? у нас одних видов оплат около сотни.

(162) Разные причины, УСН, например

да я смотрю Odavid не унимается никак... беда и печаль.
было "Франчи - позор 1с"
стало "Франчи и Odavid - позор 1с"

(166) 1С - это позор всех нас.
Но одноэсники - гордость 1С: что хотела, то и вырастила в десятикратном размере.

По производительности отписался в теме по записи в базу:
v8: v8: Есть плохая идея. Что скажете?

(166)>>было "Франчи - позор 1с"
Никогда такого не было. Франчи - настоящие одноэсники, ею выращенные, пестуемые и всячески защищаемые. Ну и пользуемые по-всякому - но все сугубо в целях и интересах 1С.
Но одноэсники "не-франчи", в полном соответствии с "1С-воспитанием", этого не видят и не хотят видеть, кроме одного - что франчи якобы "им перебегают дорогу".
И это тоже политика 1С, о чем никто не догадывается.

(160)>>ЗУП - изначально кривая система, вытесняющие регистры расчета - ... это нонсенс
Кстати, по зарплате - кому кажется, что "что кроме 1С!?"
Сравните подходы Камин и 1С к расчету зарплаты. В КАМИН нет никаких РР, "чистый" бухучет.
И конфа на ПОРЯДОК меньше (и, соответственно, проще) ЗУП. А делает все тоже самое - считает зарплату в итоге.
Да, КАМИН на платформе 1С. Но если ЗУП вы не реализуете больше нигде (нет больше нигде всего этого "<безо>разнообразия"), то КАМИН - на чем угодно, где есть возможность реализовать ПЛ.

(170) Простота Камина перед ЗУПом это, да.

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

(172) а вы не пробовали отетить на вопрос - почему при наличии других ЯП о них никто не знает, а только об 1С.
Почему в госбюджете так яростно проталкивают 1С, а не какие-нибудь Инфо-бухгалтер.
Почему от 1С большинство писается, хотя не понимает и 5% её работы и не представляет трудоемкости разработок в ней??

(167)[1С - это позор всех нас.]
своди всех тебя к психиатру

(174) психиатр вам поможет? не думаю.

(172) Загадко, однаго.

Сравнивать 1с - платформу для разработки с яп может только полный профан или троль

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

(172)у меня все сидят на камине 1.2 и счастливы. Конфигурации уже больше 10 лет кстати.
Ни проблем не затыков с ним нет. 1С надо бы поучится у Каминовцев

(179) это на семерочном камине чтоли?

(180) да на любом Камине.
Если уж 7.7 "рулит", так и говорить нечего за Камин 8.х.
Напомню, он "легче" на порядок ЗУП. И работает быстрее существенно.
(179)>>1С надо бы поучится у Каминовцев
а зачем? 1С только троллей разводит да незнаек. Вон их сколько в каждой теме.
Вот это ей любо.

(180)Кончено, конфигурация появидась когда 8-ки еще и в помине не было

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

(183)именование пременных и процедур у них свое собственное. Непривычно, есть такое дело.
Зато объем допиливания там стремится к нулю, даже при сложных расчетах

(182) когда работали на 7.7 и выбирали конфу для учета зп камин сразу отпал, т.к. сказали что максимум 1000 человек, иначе расчет будет идти очень долго. Т.ч. есть у него свои ограничения.

Нечего удивительного, сейчас тенденция такая, неуклонно падает производительность труда в РФ да и в мире, подожди чуток, может о временем наладиться

(185)строительная организация, человек 600 в год (в базе больше, т.к. текучка), строительство - куча начислений. Еще в 2005 году работали без проблем, а ведь компы тогда были какие-то селероны дешевые.
//
Там долгими могут быть только операции по закрытию месяца.
Лично у меня на 120 человек камин работал в одной базе с 2002 года и почти по сию пору. Тормозов не помню.

;-)
.
http://content.screencast.com/users/Che66/folders/Jing/media/4475d347-49d7-457a-947c-14205698115e/2013-09-16_1710.png

наш ответ сапу и всем остальным ...

(189) а я подумал, что это любимые игрушки 1с-ников, которые они располагают на своих стульчиках перед написанием своих нетленок :-)

(190) ну тогда бы было очень много 1Сников женского полу, а так - не наблюдается... ;-)

(191) как знать...если посмотреть как 1с-ники ругаются, то...как знать... ;-)

(187) у нас 4,5 тыс человек, порядка 100 видов начислений.

(193) хм... у нас примерно столько же народу да и по видам расчетов думаю где то так же. выходит нам тоже ждать эти грабли?