[likbez]

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

[Vofka]

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

[likbez]

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

[Petre]

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

[logist]

після цього у нас скінчились епітети, щоб описати їхній рівень роботи.

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

[Vofka]

Вы ждали что они взмахнут волшебной палочкой и у вас всё заработает?

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

[logist]

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

[likbez]

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

[Vofka]

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

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

[sava1]

поиск ОЧЕНЬ отличается по времени зависимо от их объема

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

Сообщение отредактировал sava1 - 22.02.18, 16:34

[logist]

фантазия у вас, конечно, богатая, но на самом деле всё не так.

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

что значит - проверять на совместимость самостоятельно? зачем тогда им платить?

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

если вы утверждаете, что поиск в базах, имеющих например 1,9 млн. записей и 4,4 млн. записей

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

[likbez]

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

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

[sava1]

поиск даже через простейшие запросы занимает в 2 раза больше времени на выполнение.

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

[logist]

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

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

[likbez]

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

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

используют толстый

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

[logist]

да, используют толстый, но так было здесь всегда;

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

поставщик не советовал (а может и вообще отговаривал от) тонкий клиент.

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

[Petre]

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

наверное потому что поставщик не советовал (а может и вообще отговаривал от) тонкий клиент.

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

[likbez]

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

[logist]

тогда сделайте нам коммерческое предложение

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

[kihor]

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

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