1С ТиС 9.2 7.70.932  доработанная, работаем в терминале, 20 пользователей, 60 тысяч позиций номенклатуры. Общий размер базы 5,5 гигов.
Обрезалась несколько раз. Работает, есть небольшие косяки (не читаемые строки, номенклатура выпадающая) но не критично.
Сейчас размер RA328.DBF 950mb. Около года еще протянем может, но задумываюсь уже сейчас, так как капец наступает всегда не вовремя.
Варианты я все знаю и они обсуждались неоднократно. Но может сейчас на июнь 2020 есть что-то новенькое.
1. Обрезка. 2.SQL 3. Восьмерка.
Что посоветуете?

Скуль

sql, и забудьте про обрезку. В случае управленческой базы, в которой формируются отчеты, обрезка объективно вредит бизнесу, ибо теряется связность аналитики.

Пока мнения не разделились ) Подождем еще голоса.

(0) Глюки начинались после перехода за 1Гб. Вот открываешь документ, а у него в ТЧ пусто, хотя точно известно, что данные там есть...
Проверить бы регистр, может быть, там партии не закрылись какие и т.п.
По идее, конечно, надо уходить на 8, но не в середине же года.

(4) RA. Какие партии, куда не закрылись?

(3) SQL нормально работает (если он нормально настроен), у меня была 7.7 - 35 гиг на SQL

а вообще поставь в план переход на восьмерку

(3) Включай голосовалку. Помнится, была примочка, которая позволяла увеличить файлик в режиме ДБФ.

(5) Ошибся, конечно же. RG у меня был когда-то больше 1Гб.

С какой скоростью растёт? А то может быть оно так ещё лет 10 расти будет

На 10 лет не хватит, на год точно, но как ить пойдет. Документов много, а сейчас цены прыгают и куча переоценок, а это тоже всё на распухание работает. Год максиммум.
На 8ку не хочу, так как эта дорабатывалась много лет по себя, так такие примочки, что в восьмерке это надо будет делать долго и дорого, а жить мы без них уже не сможем, привыкли.)
А на скуле, говорят, семерка тормозит при проведении. У меня тормозов пока нет.

1c8 sql, Файловая 8 по моему тоже имеет ограничения по размеру.

RA328 это что за таблица? она единственная критичного размера или другие тоже подбираются следом к неприятному пределу?

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

(12) Там этих критичных мест не так много окажется. Зато потом во вкус войдет и всё летать будет, особенно отчеты.

(10) Переоценки разве двигают регистр ПартииНаличие? И точно только на год хватит? А так-то можно было бы спокойненько раз в пару лет обрезАть базу и не волноваться. Собссно, у нас примерно так и получается.

(6) У нас база розницы на 7.7 скульная 130 Гб была.

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

Действительно обнаружил что при работе со скулевой базой групповое проведение жутко тормозит из-за неоптимальности построения черного запроса Рег.ВыгрузитьИтоги(). По фильтру получалось что эта команда выдается по каждой номенклатуре из таблицы документа. Хотя куда логичнее сделать это один раз а потом просто фильтровать по необходимости уже в памяти.

Кстати если кто-то может квалифицированноь подсказать по своему большому опыту что лучше изменить в конфигурации ТИС 7.7 для работы в скулевой базе - будем рады помощи наверное при успехе ее оплатим. Но именно тому что собаку съел на всем этом безобразии ).
Почта tgu82@yandex.ru
Скайп tgu_82

Сейчас работаем c DBF в терминальном режиме. База примерно 10 ГБ. Количество пользователей примерно 45.
Свертываем ежегодно из-за RА328 оставляя в базе примерно 4 года. Сейчас RA328 примерно 1.5 ГБ.

(16) Переписываются процедуры глСписаниеПартийТМЦ и глСписаниеОстатковТМЦ на прямой запрос. В остальном всё в принципе работает (работало) штатно. Ночью перепроведение, утром разбор полётов что не провелось. Когда добавилось производство, стало чуть медленнее. Дольше всего проводился документы ОтчетККМ - там было до 3 тысяч строк, 80% всего времени проведения уходило на них.

(12) Да может и больше чем в 10. Смотря что понимать под "работой", отчеты может какие и не сильно просядут, а формы справочников, журналы документов, да еще если сильно доработаны типа остаток на складе в номенклатуре, то там столько воя будет пока на табличные поля не переделают.

(16) Так обратись к toypaul - у него вроде все уже готовое есть. Получишь максимум результата с минимальными затратами труда и денег. Вроде он практикует еще.

Ну вот вообще понимания направления не добавилось. Скуль, как выясняется, всё же имеет свои косяки. "Разбор полетов утром что не провелось" совершенно мне не нравится.
Резать к чертовой матери не дожидаясь перитонита?

(19) Не знаю. Как-то больше доверяю тем кто на форуме ибо видел не раз очень умные посты помогающие вести учет.
Не в Качестве рекламы но вот очень неплохую помощь в свое время получил от Владимир1С по джейсону и 7.7 этот джейсон формирую и отсылаю через апи на сайт поставщика. Ну и вообще очень много грамотных и высокограмотных в этих вопросах форумчан. Надеюсь мое предложение не окажется безответным

(20) Не, вы неправильно поняли "не провелось". Это всего лишь задачи учёта, а не программно-аппаратная проблема ))

(20) Ну переход на скуль сам по себе не простое дело в таких объмах. Во-первых у тебя может элементарно не сработать "выгрузить базу". Файл выгрузки упрется в 2ГБ и умрет. Нужно будет искать патчи от Ромикса, а они не работают с секретным релизом :), либо смотреть доделал Альф свое исправление выгрузки.
Во вторых если выгрузка прошла успешно то может банально не загрузиться в скуль. Там какие то косяки могут быть если поля неограниченной длинны находятся не последними в реквизитах справочника, у меня кажется вылетала ошибка при загрузке документов у которых нет реквизитов шапки, что-то типа документа КнигаПокупок.
А потом даже если все удачно прошло при пересчете как пить дать какие то итоги да изменятся.

(23) Так попытка-то не пытка. Какая проблема попробовать выгрузить и загрузить?

(24) Да наверно никаких проблем, но предупреждаю что Вариант Б на самом деле не исключает варианта А :)
Т.е может для перехода на скуль понадобится сначала и базу обрезать.

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

(25) Ну вроде слава богу обрезать ничего не надо было. Засосал скуль усе

(27)+ Уже вижу что отчеты подтормаживают типа той же ведомости по контрагентов в разрезе контрагентов договоров и документов с детализацией пор операциям но не сильно.
А вот мой отчет по отгруженным оплаченным накладным - вот он на чальаном этапе тормозит. пищет ....обработка регистров
Но потом начинает работать более менее терпимо

(23) АЛьФ, почти год назад, доделал ConfigSpy http://www.dorex.pro/?projects&configspy
Сейчас выгрузка уже 2.7Gb никаких ошибок нет.
Разве что если на этапе загрузки, после распаковки, случайно нажать "нет", а потом попробовать загрузить, то не загружается. Это не критично.

(28) Журналы мне на sql не нравятся - тормозят. На 2000м сервере, насколько помню, так отвратительно они себя не вели.

(28) Это кэш включается, так что особо обольщаться не надо

(0)
1. Обрезка - временное решение. Нужно будет делать периодически и постоянно. Все равно, что сидеть на мине замедленного действия.
2. Скуль - перевёл и забыл. Есть возможность оптимизировать узкие места. Кое-что убыстрить. Можно будет работать еще лет 5-10. Риски: специалистов по 7.7 становится всё меньше и меньше. Через 10 лет их может и не быть.
3. Восьмерка - далекая перспектива, на которую следует ориентироваться, но нет смысла бросаться сейчас на эту задачу. Потребует значительных ресурсов. Как человеческих трудозатрат, так и финансовых вложений.

Вот и делай выводы.

Вывод - надо специалиста по переводу на скуль. Крутого и шарящего в семерке как у себя дома.

(33) Вот-вот. И я про то же!
Восьмерка не такая уж далекая но с 8-кой УТ и Розница все непросто именно в плане проектного внедрения.
7-ка создавалась по мере развития страны и мы росли вместе с ней.
8-ка требует планового подхода с учетом опыта тех кто в этом собаку съел и конечно это очень недешево

(33) В свое время сделал заказ крутому шарящему на несколько узких мест. А потом уже по аналогии сам остальное.

(0) у нас база обрезалась, когда размер всех дбф ~20 гигов был.
Комплексная, двойной учет в регистрах, 2 плана счетов

(34)+ Речь идет не о цене а о том в какие сроки решить море проблем первая из которых - наметить структуру учета.
8-ка в любом виде у нас так или иначе приобретена - 20 лицензий

~80 человек в терминале, активно колотящих ~20..и ничего, как-то жили с этим

(38) Ну так и мы живем только активно колотящих порядка 40 и базы здоровые. Но руководство поставило задачу - переход на скуль и все

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

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

(21) смотри новая молодежь наросла, которая не знает что такое ToySQL на 7ке :) ну ничоси

до недавнего времени сайт 1csql.ru еще жил. хз кто его подхватил, я его уже больше года как бросил. последний раз библиотеку продал в прошлом году. в этом году заработал целых 500 руб на доработке своего отчета :)

(42) Тут молодежь подросла которая вообще не понимает как в 7-ке все устроено.... Стареем.... :)

(43) Ну с ними-то все понятно. Не понятно как можно на 7ке работать и не знать что такое ToySQL, ну хотя бы 1С++ которое еще живое

(44) Как раз тут все понятно: разная скорость развития информационной системы.

Тут как с развитием цивилизаций: кто-то уже развился и в космос полетел, а кто-то еще с мотыгой сидит.

(43) есть молодежь, которая обычных форм в восьмерке не видела...

(44) Ну, вот например, я с toysql ни разу не работал.
Правда, с rainbow, а потом с 1c++ - достаточно много...

(44) я примерно знаю, хотя живьем не видел. Но вроде часть ее вошла в 1с++, еще на ее заре?

(42) Посей день вспоминаем тебя хорошим словом... за TOYSQL

(47) "не знал" и "не работал" это разные слова. и даже смысл разный у них

(49) а я не вам исходники продал :) ? по-моему из Красноярска кому-то ...

(50) Ну как... Слышал, так точнее было.

(51) нет... мы на TOYSQL уже лет 10

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

(51) А "управляемые блокировки" в ToySQL были, или это был отдельный продукт? Не помню уже...

(51) мы никак не разродимся на переход на 2005 SQL....

(53) Фиг знает. Наверное можно Вам позавидовать

(55) Это же МуМу, Софтпойнт

(55) были. в составе набора оптимизации для ТИС, Комплексной

почему были. и есть. и пользуются

(57) прямые запросы позволяют ненапряжно перейти на запросы снеговика.

(55)  Объект ToyBlocking шел в комплекте

Ну, "были" - для меня лично. Сбежал с 7.7 как только появилась возможность. Все-таки 7.7 была уже чудовищно архаична на момент появления 8-ки.

За ToySQL обидно было, да. Отличный продукт, просто появился с опозданием.

(63) Очень и очень много ТИС ПУБ и даже БУХ на 7-ме на самом деле. Перевести многозвенную структуру на 8-ку - совсем не просто хотя и крайне необходимо.

(64) ну как это рано ... в 2002 году где-то. тогда СКЛ на 7ке только на ноги вставал

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

(0) Поставьте dll для работы дбф более 1 гига. И до 2 гигов живите на дбф.

(63) "архаично - зато дешево, доступно и практично!"©

(67) Rainbow -> ToySQL -> 1C ++

1С++ появилась вместе с ToySQL, но функционал работы с запросами позже. по датам не помню уже

(69) Шурик, это же не наш метод (с)

(30) все тормоза после загрузки данных в новую SQL базу могут быть из за кривой статистики - надо на скуле регламенты проверить, настроить и обновить статистику.
у нас после перехода в ЗУП 3.1 работать было вообще невозможно, после загрузки данных, после обновления статистики стало все летать.

(71) "а теперь со всей этой фигней мы попробуем взлететь..."

(70) Тогда норм, вроде...

(70) Тогда 1С++ подкосила :)

(75) так в 1с++ вроде работа с запросами - как раз вклад Павла?

(76) частично да. функционал работы с запросами мой. но с грязными. в 1С++ потом уже свои метазапросы прикрутили. и всякие "классы"

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

8ка подкосила. но долго это продлилось ...

(78) Вот если бы воспользоваться Вашей помощью тоже. Но тут как бы все малость разнопланово
1. Выполнение группового перепроведения документов (очень медленно, причем сразу медленно)
2. Работа с файлами на диске (типа НайтиСледующий и т.д.) (медленно)
3. Выполнение отчетов типа ведомость по контрагентам к примеру (медленно)
ну и т.д. - то чего не не разглядел

(0) способ 4. проанализировать, возможно регистр вырос из-за незакрытых итогов или иного не оптимального хранения данных (лишние данные) исправив это уменьшить размер регистра
банальный пример - партии не закрываются и разбух регистр

(80) Ещё один с итогами... Написано же RA. Какие итоги?

(82) перепутал с таблицей остатков, суть та же, посмотреть, может быть можно от каких-то разрезов отказаться, например не исполдьзуется ресурс СуммаУправленческая - от нее попробовать избавиться с корректировкой конфы

(82) ЦенаПрод не используется, она и ПартииНаличие и в ОстаткиТМЦ. И сто лет она не нужна но надо конфу править.
Насколько уменьшится регистр RA - надо смотреть, но думаю малосущественно это будет

(79) я сейчас советом в этом направлении не даю. продать могу. а дальше сами. есть проведение, есть отчеты, есть даже параллельное проведение. работа с файлами это не по моей части. и да. это если конфа типовая ТИС или ее клон "уехавший" не сильно далеко

(83) Посмотри еще СуммуУпр и СуммуРуб, если равны то СуммаУпр или наоборот, вообще не нужна.
И точность и/или максимальная величина чисел там великовата. Можно из итогов проверить.

SELECT
    max(Количество)     [Количество $Число.15.5]
    ,max(СуммаРуб)     [СуммаРуб $Число.15.2]
FROM РегистрИтоги_ПартииНаличие

А насчет "но надо конфу править" так с sql значительно больше править придется ;)