Добрый день!
Давно читаю форум, но со своей проблемой впервые решила к вам обратится.
Подскажите пожалуйста, кто сталкивался с такой ситуацией.
Версия Cache 4.1.3.
Проверка на целостность не дает ошибок - ни в целом база, ни конкретный глобал.
Но! Когда проходим глобал по $o на битом индексе цикл вылетает с ошибкой <SUBSCRIPT>, сам индекс я не знаю и как его определить пока не придумала.
При экспорте глобала в разных вариантах смогла добиться ошибки
ОШИБКА #570: Глобал ^FC содержит управляющие символы.
Восстановление этого глобала может завершиться неудачей

ser_shu,
пробовала, но индекс там не инкремент. Поэтому не особо помогает.

krvsa,
Вот в том то и дело, что он его не берет и вывести его не могу.

9786**1000***** ; предыдущий индекс

FOR S a=$O(^FC("Spr","SPR",1,a)) Q:a="" W a,!
^
<SUBSCRIPT>

а вот следующий уже не берет

krvsa, $QUERY дает тот же <SUBSCRIPT>
А насчет выгрузки в xml можно поподробнее? Это вы про экспорт?

DAiMor ,
увы...
BAZ>d $system.OBJ.Export("FC.GBL","c:\fc.xml")
Экспорт в XML начался в 08/15/2011 13:55:26
Экспортируемый глобал: ^FC
<SUBSCRIPT>outputClass+178^%occXMLExport


Из-за чего вообще мог появится такой индекс? И как с этим бороться?

krvsa , все равно спасибо за помощь)
Буду ждать!

Блок А.Н. ,
у меня появилось несколько вопросов.
1) do ^INTEGRIT - не выдает ошибки
2) do ^REPAIR - с помощью этого я нашла 2 записи, которые у меня битые
Они даже как то странно в терминале вывелись, откуда многоточия????
^FC("Spr","SPR",1,"9787*1*56*30*"...)
^FC("Spr","SPR",1,"9787*1*56*50*"...)
Остальные записи в виде
^FC("Spr","SPR",1,"9790*101*1517*****")

вопрос состоит в том, как их можно исправить по нормальному или только скопировать до/после?
Просто записи очень надо восстановить... А текстовка там вывелась как

И такую ситуацию удалось обнаружить только уже целеустремленным поиском, когда стало известно в какой ветке глюк происходит.
А как быть если неизвестно где такой битый индекс? База под 8Гб, не будешь же каждый глобальчик в $order пропускать. Есть какие то другие пути решения? (с учетом того что проверка целостности говорит что все-все цело).

Блок А.Н.REPAIR восстанавливает блочную целостность, интегрит проверят ее же.
Значит с этим все нормально, просто в самом глобале что-то не то.

А вы настрояки локали, языков не меняли?
Если попробовать поднять базу на UTF8 кодировке?

Ничего не меняли. Насчет кодировки UTF8 не могу ничего сказать - надо будет проверить.
ПО работало довольно долго стабильно. Откуда появились такие битые индексы???

ser_shupandorrayОни даже как то странно в терминале вывелись, откуда многоточия????
^FC("Spr","SPR",1,"9787*1*56*30*"...)
^FC("Spr","SPR",1,"9787*1*56*50*"...)
Остальные записи в виде
^FC("Spr","SPR",1,"9790*101*1517*****")

похоже на индексацию набора полей, разделенных *.
Тогда, скорее всего в наборе полей "9787*1*56*30*"... в пятом поле попал спецсимвол, который потом попал в индекс.
Если у Вас такая структура - попробуйте найти эти данные, исправить и снова записать индекс.
Только желательно в этом поле со спецсимволом точно определить содержимое, чтобы уничтожить "плохой" индекс.

В пятом поле не должен был попасть спецсимвол - там должно было быть число, но чем черт не шутит)

servit pandorray ,

Почему записались неверные данные сейчас сложно сказать, но можно попробовать в рамках процесса временно включить NullSubscripts и посмотреть исчезнет ли ошибка <SUBSCRIPT> при проходе по глобалу: $ZUTIL(68,1) -- Null Subscript Mode Process Switch

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

Спасибо за совет. Проверила. Но увы... Ошибка <SUBSCRIPT> все равно выскакивает при проходе по глобалу.

Alexey Maslovmisha_shar,

как же она вырежет индекс, если прога вылетает по <SUBSCRIPT>.
Кстати, начиная с Cache 4.1 (с появлением "нового" формата БД), запрет на управляющие символы в индексах был снят. Например,

Вы, правы, я проверяла вот таким методом, и все индексы читаются в проводнике, проходятся по $o

Поэтому я и понять не могу что ж за символ туда мог попасть...