| 0
- 02.08.2017 - 16:12
|
Впервые с таким столкнулся. Платформа при при переиндексации базы вдруг стала "вылетать". Приложение просто закрывается и все, причем стабильно на одном и том же справочнике, в котором от силы 50 элементов, но куча полей(фдажков) с признаком - сортировка. Причем, база много лет работает. Если же все индексные удалить, то база успешно индексируется и успешно работает. Сама база после свертки зимой небольшпя, меньше 2 гигов. Файловый вариант, работа в терминале. В обсуждаемый файл недавно добавлял поле, но пробовал, удалял, все равно вылетает. Ерунда какая то. Разве при переиндесации платформа сама не удаляет индексные файлы. И почему вообще ей вылетать )
    | | |
| 1
- 02.08.2017 - 16:14
| Причем этот справочник настроечный, в него во время работы никто ничего не пишет, он условно постоянный | | |
| 2
- 02.08.2017 - 18:35
|
хм.. что-то там смутно припоминается такая фича, что если реквизит неограниченной длины, то надо его сделать последним в списке реквизитов. ну мало ли, к примеру в той же ТиС наименование ограничено, а полное наименование - нет, вдруг и у тебя индекс типа по полному наименованию. но это так мне смутно припоминается, щас гуру подтянутся, вспомнят про эту фичу подробнее. Или не про эту. ************************************************** ******* ps: И эта, у тебя платформа часом не sql? Не база, понятно, что база файловая, а именно сама платформа? А то многие ставят многие ломаную не глядя. Нет, я ни на что не намекаю, просто ну а вдруг.. | | |
| 3
- 02.08.2017 - 18:44
|
Ну и естественно, неплохо бы для очистки совести глянуть, нет ли у тебя в индексируемых полях какого-нибудь мусора, типа неотображаемых символов ("кракозябров"). А то при попытке "построить индекс по кракозябрам" 1С-ина бывает впадает в кому. Просто глянуть. Любым приличным dbf-редактором. | | |
| 4
- 02.08.2017 - 19:54
|
реквизит неограниченной длины - это не из той оперы, это про загрузку в SQL базу. У меня нет там таких строк. Там код, наименование, пара периодических реквизитов (расценка работ) и флажки N(1) с признаком [x] - сортировка У меня же 2 вопроса: 1 - почему ваще вылетает 2 - почему при удалении cdx успешно инлексирует Завтра специально поэкспериментирую. А движок SQL, но база файловая | | |
| 5
- 02.08.2017 - 22:09
| (0) Попробуй переместить базу. Выгрузка/загрузка. Как определил, что на этом справочнике рушится? Возможно, что на следующей таблице. | | |
| 6
- 03.08.2017 - 00:14
| индексирование диска с базой отключено? | | |
| 7
- 03.08.2017 - 04:36
|
(5)Может конечно и не на нем, его последний выводит платформа перед падением. Может и следующий. Надо посмотреть что там за ним. Просто он последний из того, что недавно менял.Копия кстати по моему без проблем индексируется, причем горячая копия, с сидящими в базе пользователями (6)я не админ, там другие этим занимаются. в свойствах диска галочка стоит. Где служба настраивается не знаю, в 2008 SERVER она где то в другом месте вроде, но сервак не меняли | | |
| 8
- 03.08.2017 - 04:58
| нет, с копией тоже фигня. Взял базу, не требующую индексации, скопировал, зашел, ничего в ней не делал, процесс срубил. Переиндексирую - вылетает, но не видно было на чес слетает | | |
| 9
- 03.08.2017 - 05:28
| Тестирование физической целостности ничего не выдало | | |
| 10
- 03.08.2017 - 06:54
| Итак, докладываю. Базу выгрузил. Загружаю, не загружается, вылетает. Стал смотреть какой последний по времени файл создался - SC16757.CDX. После него по словарю (1СV7.DD) SC14986. Это не мой подозреваемый, решил проверить иначе. Удалил все индексы, переиндексировал и опа, за SC16757.CDX идет SC3992.CDX, это как раз мой голубчик, в который недавно добавил реквизит. Захожу, убираю с нового реквизита сортировку, пытаюсь сохранить, база индексируется (так как недоиндексировалась) и 1с вылетает. Удаляю индексы, переиндексирую, убираю флаг сортировки с реквизита, запускаю, снимаю процесс 1c, индексирую и ВСЕ ИНДЕКСИРУЕТСЯ. все снова работает. Это числовое поле N(1) с признаком сортировки. Просто есть куча флажков, идентифицирующих различные операции. Возвращаю флажок сортировки, запускаю, процесс 1с срубаю, индексирую и.. НЕ ИНДЕКСИРУЕТСЯ.Вот такая интересная штука. Куда ж теперь дальше копать ?) | | |
| 11
- 03.08.2017 - 07:27
| Поставил сортировку на мой реквизит, но убрал с другого, все работает. То есть получается, что косяк с числом индексируемых полей. В 1cv7.dd насчитал 63 или 64 индекса, то есть всего порядка 30 индексируемых полей. Размер индексного файла примерно 100 килобайт, сама таблица - 15 килобайт. При таких размерах я и не задумывался о целесообразности использования моих индексируемых полей с типом N(1), но они реально нужны, либо надо много переделывать, эмулируя предопределенные элементы справочника. Интересная штука получается, у задачи наступил технологический затык ?) | | |
| 12
- 03.08.2017 - 07:38
| Вернул все сортировки, но сделал справочник одноуровневым (число уровней 4 досталось от типовой ПУБ, справочник "Техоперации", на это никакого внимания не обращал), ВСЕ РАБОТАЕТ. Число индексов у справочника уменьшилось вдвое. Такая вот загогулина ))) | | |
| 13
- 03.08.2017 - 12:02
| Цитата:
А вот на количество самих индексов ограничения не помню.. хотя, у 1С же не стандартный dbase, у нее свой xbase, те же memo-поля они реализовали по-другому. | | |
| 14
- 03.08.2017 - 12:11
| (13)Индексные выражения все короткие ) Не знаю какие ограничений у 1с, но вот ситуация такова, как описал. Самая то странность, почему при удаленных индексных файлах все индексируется? Но в тоже время загрузка базы не выполнялась. В Фохпро по моему просто ограничение на длину строки - 255. С dbase я плотно не работал, foxpro то уже почти забыл. Да, мемо поля совсем по другому, засунули все в один бедный файл ) | | |
| 15
- 03.08.2017 - 12:13
| Кстати, года 2 назад был фокус с числом панелей интерфейса, вот не помню только количество, вроде 10. После добавления очередной панели были косяки, не помню точно, но вроде весь интерфейс испарился ) | | |
| 16
- 04.08.2017 - 00:44
| есть проблемы с общей длиной ключа - не надо делать чтобы ключ был больше ~160 символов - что-то типа такого... | | |
| 17
- 04.08.2017 - 01:14
| .. и для реиндексации и построения индексов с нуля - используются разные алгоритмы | | |
| 18
- 04.08.2017 - 01:25
| ..и есть ограничение на количество индексов | | |
| 19
- 04.08.2017 - 01:33
|
цитриую мастеров: "Индексация с нуля делается в рабочих файлах путем "алгоритма слияния" последовательных упорядоченных груп записей. Условно говоря !!!. А ренидексация - это непосредственная работа с деревом индекса." итого: работа с деревом - существенно более зтаратная - надо вставлять/удалять/сдвингать/раздвигать... | | |
| 20
- 04.08.2017 - 01:34
| ..при работе с деревом всякие расщепления/слияния страниц и прочие лабутены.. поэтому и пухнет и напарывается на ограничения и бряк! | | |
| 21
- 04.08.2017 - 05:58
|
Создал пустую конфигурацию, добавил в нее объединением мой справочник (естественно с заменой ссылочных полей на строковые), получил чистую базу с одним справочником. Больше вообще ничего. Для чистоты эксперимента - справочник без элементов. Поведение тоже самое, как только делаю справочник многоуровневым платформа слетает при аварийном индексировании. При удалении всех индексов - индексируется. Если убрать сортировку с последнего реквизита типа N(1) то все работает и при многоуровневом справочнике. Вот индексы из DD: #----Indexes------ # Name |Descr |Unique|Indexed fields |DBName I=IDD |of ID |0 |ID |IDD I=PCODE |of PARENT and |0 |PARENTID,ISFOLDER,CODE(UPPER) |PCODE I=PDESCR |of PARENT and |0 |PARENTID,ISFOLDER,DESCR(UPPER) |PDESCR I=CODE |of CODE |0 |CODE(UPPER) |CODE I=DESCR |of DESCR |0 |DESCR(UPPER) |DESCR I=VI19 |VI19 |0 |SP19 |VI19 I=VIP19 |VIP19 |0 |PARENTID,ISFOLDER,SP19 |VIP19 I=VI20 |VI20 |0 |SP20 |VI20 I=VIP20 |VIP20 |0 |PARENTID,ISFOLDER,SP20 |VIP20 I=VI21 |VI21 |0 |SP21 |VI21 I=VIP21 |VIP21 |0 |PARENTID,ISFOLDER,SP21 |VIP21 I=VI22 |VI22 |0 |SP22 |VI22 I=VIP22 |VIP22 |0 |PARENTID,ISFOLDER,SP22 |VIP22 I=VI23 |VI23 |0 |SP23 |VI23 I=VIP23 |VIP23 |0 |PARENTID,ISFOLDER,SP23 |VIP23 I=VI25 |VI25 |0 |SP25 |VI25 I=VIP25 |VIP25 |0 |PARENTID,ISFOLDER,SP25 |VIP25 I=VI26 |VI26 |0 |SP26 |VI26 I=VIP26 |VIP26 |0 |PARENTID,ISFOLDER,SP26 |VIP26 I=VI27 |VI27 |0 |SP27 |VI27 I=VIP27 |VIP27 |0 |PARENTID,ISFOLDER,SP27 |VIP27 I=VI31 |VI31 |0 |SP31 |VI31 I=VIP31 |VIP31 |0 |PARENTID,ISFOLDER,SP31 |VIP31 I=VI35 |VI35 |0 |SP35 |VI35 I=VIP35 |VIP35 |0 |PARENTID,ISFOLDER,SP35 |VIP35 I=VI38 |VI38 |0 |SP38(UPPER=128) |VI38 I=VIP38 |VIP38 |0 |PARENTID,ISFOLDER,SP38(UPPER=128) |VIP38 I=VI41 |VI41 |0 |SP41 |VI41 I=VIP41 |VIP41 |0 |PARENTID,ISFOLDER,SP41 |VIP41 I=VI42 |VI42 |0 |SP42 |VI42 I=VIP42 |VIP42 |0 |PARENTID,ISFOLDER,SP42 |VIP42 I=VI43 |VI43 |0 |SP43 |VI43 I=VIP43 |VIP43 |0 |PARENTID,ISFOLDER,SP43 |VIP43 I=VI44 |VI44 |0 |SP44,DESCR(UPPER) |VI44 I=VIP44 |VIP44 |0 |PARENTID,ISFOLDER,SP44,DESCR(UPPER) |VIP44 I=VI45 |VI45 |0 |SP45 |VI45 I=VIP45 |VIP45 |0 |PARENTID,ISFOLDER,SP45 |VIP45 I=VI46 |VI46 |0 |SP46 |VI46 I=VIP46 |VIP46 |0 |PARENTID,ISFOLDER,SP46 |VIP46 I=VI47 |VI47 |0 |SP47 |VI47 I=VIP47 |VIP47 |0 |PARENTID,ISFOLDER,SP47 |VIP47 I=VI48 |VI48 |0 |SP48 |VI48 I=VIP48 |VIP48 |0 |PARENTID,ISFOLDER,SP48 |VIP48 I=VI49 |VI49 |0 |SP49 |VI49 I=VIP49 |VIP49 |0 |PARENTID,ISFOLDER,SP49 |VIP49 I=VI50 |VI50 |0 |SP50 |VI50 I=VIP50 |VIP50 |0 |PARENTID,ISFOLDER,SP50 |VIP50 I=VI51 |VI51 |0 |SP51 |VI51 I=VIP51 |VIP51 |0 |PARENTID,ISFOLDER,SP51 |VIP51 I=VI52 |VI52 |0 |SP52 |VI52 I=VIP52 |VIP52 |0 |PARENTID,ISFOLDER,SP52 |VIP52 I=VI53 |VI53 |0 |SP53 |VI53 I=VIP53 |VIP53 |0 |PARENTID,ISFOLDER,SP53 |VIP53 I=VI55 |VI55 |0 |SP55 |VI55 I=VIP55 |VIP55 |0 |PARENTID,ISFOLDER,SP55 |VIP55 I=VI56 |VI56 |0 |SP56 |VI56 I=VIP56 |VIP56 |0 |PARENTID,ISFOLDER,SP56 |VIP56 I=VI57 |VI57 |0 |SP57 |VI57 I=VIP57 |VIP57 |0 |PARENTID,ISFOLDER,SP57 |VIP57 I=VI60 |VI60 |0 |SP60 |VI60 I=VIP60 |VIP60 |0 |PARENTID,ISFOLDER,SP60 |VIP60 I=VI68 |VI68 |0 |SP68 |VI68 I=VIP68 |VIP68 |0 |PARENTID,ISFOLDER,SP68 |VIP68 | | |
| 22
- 04.08.2017 - 06:02
| SP68 - это безобидный флажок, портящий кровь ) При количестве уровней = 1 все составные индексы по ISFOLDER (признаку группы) не строятся. Я грешу только на общее количество индексов. На досуге уберу уровни и просто навтыкаю полей с сортировками, их тут около 30 | | |
| 23
- 04.08.2017 - 06:19
| Создал дополнительно 40 простых полей с сортировкой - вылетает, 35 - вылетает) | | |
| 24
- 04.08.2017 - 06:24
| При 3- дополнительных полях ошибка уходит, всего индексов по моему 63. Видимо ограничение 64 )) | | |
| 25
- 04.08.2017 - 06:33
| Короче лень считать, но по строкам в dd выходит, что при 61 индексах работает, при 62 уже нет ) Так что не увлекайтесь полями с сортировкой, даже в пустом справочнике )) | | |
| 26
- 04.08.2017 - 07:57
| 25-USSR >Спасибо за исследование, принял к сведению... - тоже наталкивался на проблему сортировки. | | |
| 27
- 04.08.2017 - 17:51
|
21-USSR > "Поведение тоже самое, как только делаю справочник многоуровневым платформа слетает при аварийном индексировании. " - помниторь расход памяти ? | | |
| 28
- 04.08.2017 - 18:55
| (27)Памяти дофига и какой расход памяти при индексации базы, состоящего из одного пустого справочника. То есть в базе вообще ничего нет. Ни метаданных, ни данных )) | | |
| 29
- 05.08.2017 - 00:08
| видеопамяти, например ))) | |
Интернет-форум Краснодарского края и Краснодара |
