після запропонованого постачальником поновлення конфігурації з версії 1.2 до версії 2.0 виникли наступні проблеми:
1 - став неможливим імпорт виписок з клієнту-банку у форматах dbf, а ПЗ клієнт-банк не підтримує формт xml, тобто ефективна робота бухгалтерії ВЖЕ стала неможливою.
2 - розмір бази даних зріс БІЛЬШ ніж удвічі - з 1,9 Гб до 4,3 Гб. Тобто - відповідно вдвічі сповільнилась робота інших клієнтів з цією базою.
3 - рекомендований підтримкою постачальника запуск тестування та виправлення БД вже триває майже пів робочого дня (з 10% прогресу) і його завершення сьогодні не очікується, тобто робота бухгалтерії (відповідйно - і всього підприємства) паралізована повністю.
в результаті - постачальник конфігурації НЕ ЗНАЄ відповіді на наведені запитання і пропонує зачекати декілька (!) днів.
після цього у нас скінчились епітети, щоб описати їхній рівень роботи.
допоможіть, будь ласка, порадою, хто знає.

1. Скорее всего нужно писать обработку под бухгалтерию 2.0
2. Размер базы и скорость работы не имееют линейной зависимости. Нужно анализировать ситуацию
3. Такие вещи следует выполнять на копии базы, т.к. результаты ТиС может привести к неожиданным, в неприятном смысле, сюрпризам

3. копии базы, конечно же, были сделаны ДО апдейта конфигурации, но мы не можем остановить деятельность предприятия, пока не будет достигнута полная работоспособность новой конфигурации. Также не хотелось бы делать двойную работу, вводя сотни если не тысячи созданных в этот период документов по второму кругу.
2. размер прямо влияет на скорость при работе по сети, так как работа с файлом 4 Гб однозначно медленнее, чем с файлом 2 Гб, даже если бы это был другой файл, не база 1С.
1. есть ли где-нибудь инструкция, как её писать? интересно, конечно, почему она не только не была написана ДО момента обновления поставщиком, но он про это даже не знал.

likbez @ Сегодня, 16:39 необходимо зарегистрироваться для просмотра ссылки ,
1. Типова обробка непрацездатна як у 1.2, так і у 2.0. Стороння обробка, що працювала у 1.2, не буде працювати у 2.0 - треба оновлювати / переходити на іншу.
2. Після оновлення розмір збільшується. Для його скорочення можна використати відповідну опцію у тестуванні та виправленні.
3. Повне тестування та виправлення варто було робити на базі 1.2 з метою пошуку та виправлення помилок. На 2.0 натомість спробуйте зробити вивантаження / завантаження.

Вы ждали что они взмахнут волшебной палочкой и у вас всё заработает? Проблема длительного тестирования это особенность конкретной базы, служба поддержки без анализа базы ничего не скажет. Это как лечить перелом ноги по телефону, вы сломали её, и просите врача что бы он помог вам словами, а слова перелом не лечат... Второе - размер базы, если она у вас файловая, и работает так много пользователей которые вводят сотни, тысячи документов в день-два, то надо задумываться над переходом в серверный вариант. Но в любом случае размер базы на работу по сети, или не по сети никак не влияет, от источника данных (сервер или файл) до клиента (приложение) передается лишь необходимый, для текущей процедуры, объем данных. Вы представляете себе это так, как будто зашли в аптеку купить аспирин, и ради одной пачки у аптеки строят целый завод.
Клиент-банк, тут тоже вины разработчиков нет, т.к. все дополнительные модули, которые не входят в основную поставку, а КБ в вашем случае таким является, вы должны проверять на совместимость самостоятельно (либо привлекая специалиста).

Очень часто франчи (да и любые другие продавцы) именно так и говорят, когда впаривают что-то.

Клиент же тоже должен думать, а если не разбирается то задавать вопросы, искать информацию самостоятельно. Ведь если покупают продукт для большого объема данных и количества пользователей, то надо всё изучать и продумывать, иначе покупка может стать мучительной. Бывают такие клиенты которые и слушать ничего не хотят, им знакомый Петя сказал что надо "вот это" и всё, а то, что оно ему не подходит или в будущем вызовет какие-то дополнительные траты и/или проблемы - пофиг, и когда этот момент настает - начинают винить всех вокруг, что ему продали говно-продукт. Ситуаций бывает много разных.

logist @ Сегодня, 11:31 необходимо зарегистрироваться для просмотра ссылки ,
фантазия у вас, конечно, богатая, но на самом деле всё не так.
1 - у нас несколько рабочих мест, откуда создают в среднем по 10-20 счетов каждый день, но, учитывая медлительность и бесперспективность вендора - их насобирается не одна сотня, после решения проблем с новой базой нужно будет вручную всё это создавать в ней.
2 - никто не ждал волшебных палок, поставщик (который получает за это регулярную оплату от нас не первый год) сам предложил обновить конфигурацию. Зная формат экспорта нашего клиент-банка (DBF - а не XML), как и остальную специфику конкретно нашей компании - он взялся через удалённый доступ обновлять и платформу, и конфигурацию (хорошо хотя бы мы успели сделать бэкап существующей базы). когда после обновления выяснилось, что обмен з клиент-банком невозможен, он отвечает - решения нет, но со временем оно появится. неужели это звучит нормально? что значит - проверять на совместимость самостоятельно? зачем тогда им платить? мы и апдейты сами могли бы устанавливать. но если мы платим за поддержку, то ожидается, что она будет адекватной, так как база бухгалтерии - критически важный элемент инфраструктуры нашей компании.
3 - если вы утверждаете, что поиск в базах, имеющих например 1,9 млн. записей и 4,4 млн. записей - должен занимать одинаковое время, то вам нужно учить мат.часть, так как кроме 1С, МЕДок, правовых баз и т.п. у нас используются еще и простые реляционные БД в форматах Cronos и Access - как раз с миллионами записей внутри, и практика показывает, что поиск ОЧЕНЬ отличается по времени зависимо от их объема.

Если вы думаете, что база данных это просто набор записей, то мат. часть нужно учить вам.

Учите матчасть, а не щеголяйте выражениями типа "реляционная БД".

Это не фантазия, а опыт работы.


Если кому-то платите, значит они должны проверять. Если не проверили, значит не выполнили свою работу. Тогда все ваши претензии обоснованы, и вы имеете право предъявлять им претензии по качеству работы. Например, у меня в таких случаях предварительно обговариваются с клиентом все моменты перехода, и пока на переход на 2.0 решился только один. Мы перевели свою бухгалтерию на 2.0 и сделали вывод, что не можем пока советовать клиентам переходить на неё.
p.s. если вас обслуживает фирма по договору ИТС и консультируетесь вы с ней, не оперируйте понятием Поставщик конфигурации, это другая организация.


Мы говорили про РАЗМЕР ФАЙЛА базы данных, в конкретном случае 1С (а у неё есть свои особенности, и выше вам предложили вариант при котором её можно попробовать уменьшить), а не о количестве записей в ней, и поиске по ним.

практика показывает, что при одинаковом количестве полей в таблицах БД и подобном объеме данных в аналогичных полях записей 2-х БД - файл БД с количеством записей в 2 раза большим - занимает на диске приблизительно в 2 раза больше места, и поиск даже через простейшие запросы занимает в 2 раза больше времени на выполнение.
а еще одна практика вчера тоже показала, что после увеличения данного конкретного файла более чем в 2 раза клиенты по сети наблюдают приблизительно двукратное понижение скорости работы с привычными для них операциями в 1С. и это всё несмотря на упомянутые вами особенности 1С. предложенный вариант хотя и занял почти сутки, но уменьшил размер на 40%, но нет никаких гарантий, что когда-то позже не найдутся проблемы из-за этого.
за информацию о своем опыте перехода - спасибо!

Покажите мне реляционную БД, где поиск осуществляется сканированием таблиц.

Странно, что вы связываете это только с размером файла базы, ведь данные решения (1 и 2 редакция) написаны по разной технологии, и во второй исполняемого кода как минимум на 50% больше. Здесь сначала надо спросить - клиенты для работы используют толстый или тонкий клиент? Если толстый, то переведите всех на работу в тонком.

признаю свою ошибку: неуместно употребил термин "реляционную". но от этого не легче.


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

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


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

Поставщик некомпетентный.

Petre @ Сегодня, 14:15 необходимо зарегистрироваться для просмотра ссылки ,
тогда сделайте нам коммерческое предложение (небюджетное госпредприятие с НДС, сфера - информационные услуги).

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

Зависит от селективности запроса. Если оптимизатор определяет, что дешевле использовать full scan, чем индекс, то будет сканирование таблицы. Так работает и MSSQL и Oracle (думаю, что DB2 также - не работал с ней). Как это происходит в файловой базе 1С я не знаю, честно говоря.

Выставляйте счет "такому поставщику"
Срыв рабочего процесса по вине поставляемого ПО, в рамках договорных отношений.
В суд с такой проблемой не пробовали обращаться?

По поводу КБ скажу, что на самом деле всё довольно просто, но масштабно. Код из родного КБ никогда не использовал, почти под каждый банк писал с нуля =(. Что самое смешное, что за окном 2018, а многие банки так и передают данные в dbf =(