0
- 09.08.2016 - 16:29
|
Заранее спасибо за ответ
| |
41
- 07.09.2016 - 12:51
| (40)Обновления практически не пропускались. Я не вполне понял мысль почему уникальные идентификаторы в медленной не совпадают? а как тогда объекты сопоставляются - по имени ? и происходит потеря скорости? Получается, что типовая + N обновлений <> не равно новой N-типовой ? я думаю, что ты прав и это как то так и есть, но что делать практически? как оживить медленную, с учетом того что реально она должна быть немножко не типовая )) | |
42
- 07.09.2016 - 13:07
| (41) обнови старую типовую (проверь быстро ли первое обновление) релизов на 15-20 и будем знать точно ))) | |
43
- 07.09.2016 - 13:15
| щас неохота, но сделаю ) засада какая то ) второй день убил, а толку никакого. Мне все таки кажется, что я где -то криво обновил | |
44
- 07.09.2016 - 13:52
| посадил медленную всю на замок. Все равно медленная. Неохота типовую обновлять, мне все равно корректно не воспроизвести. С замками смысла нет, без замков надо | |
45
- 07.09.2016 - 14:36
| (44) если загрузить в неё конфу из быстрой ? | |
46
- 07.09.2016 - 15:50
| (45)я так и хочу попробовать на копии рабочей базы. Возьму типовую чистую, внесу изменения из моей объединением и потом попробую загрузить. Не уверен правда что прокатит нормально, не получится ли фигня с метаданными. А медленная еще интересна тем. что из нее сравнение идет медленно, и с ней тоже медленно ) | |
47
- 07.09.2016 - 21:38
| (46) метаданные пофигу ))), интересно что со скоростью будет | |
48
- 07.09.2016 - 23:12
|
Докладываю. 1 - создал копию базы (3.0.44.102 с изменениями) 2 - сохранил из нее конфигурацию в файл Исходная.cf 3 - сделал проверку физической и логической целостности, только тестирование (все ОК) 4 - взял типовую 3.0.44.102 5 - объединением с сохраненной конфигурацией внес в нее нужные мне изменения. Выгрузил конфигурацию в файл ДляЗагрузки.cf 6 - загрузил в базу конфигурацию ДляЗагрузки.cf При обновлении конфигурации базы данных весьма долго хрюкала. До этого по ошибке загрузил самое себя, так не хрюкала ) 7 - сделал проверку физической и логической целостности, только тестирование (все ОК) 8 - запустил. Проводки по подразделению на месте, общие реквизиты на месте Обновил сначала на 103, потом на 104. Сравнение идет быстро. Сохранение конфы и обновление базы при обновлении на 103 почему то шло минут 20, не засекал, но точно не меньше, скорее всего с полчаса. Вернулся к 102 и обновился сразу на 104. Все обновилось очень быстро, прямо как БП 2.0 Попробовал сравнение с типовой - моментально. У "медленной" базы это было 20 с лишним минут. Может косяки вылезут, но по идее не должны. Что там сидело во внешне такой же конфигурации - непонятно. Короче все стало быстро, я уже и не знал что так бывает. В выходной проделаю это на рабочей базе. И потом понаблюдаю. Завтра посмотрю еще 2 базы. Там а принципе такая же история. В общем либо я я когда то накосячил с обновлением, либо у 1С было кривое промежуточное обновление. Обсуждаемую базу обновлял регулярно, наверное без пропусков. Будущие 2 с большими, но рекомендуемыми пропусками. Но еще до низ скорость была не фонтан, это еще наверное на 3.42... Вот такая история. "Медленную" конфигу сохраню, может и в 8.3 появятся умельцы, которые что-то изобретут для анализа. | |
49
- 07.09.2016 - 23:21
| Забыл написать. Что в медленной, что в нормальной конфигурации обновление конфигурации поставщика было наверное (визуально) с одной скоростью, но после этого в медленной индикатор медленно и нудно полз с выводом наверное всех имен метаданных, а в быстрой просто мухой все сравнивалось. Но результаты сравнения были идентичны. Все объекты были на замке, кроме измененных мною. Они были на поддержке | |
| Интернет-форум Краснодарского края и Краснодара |