|
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум | |
|
Лисоводы всех стран, объединяйтесь !!! |
| Индексы 9-ки ......... | |||
|---|---|---|---|
|
melnik Автор Сообщений: 289 Откуда: г. Владимир |
Всех приветствую !!!!!!!!!!!!!!!!!!!!
Люди вот такая ситуация : Перевёл свой рабочий проект, на 9-ку. До этого юзал 8-ку. Почти сразу столкнулся с проблеммой ошибочных индексов . То в одном, то в другом филиале вылетало сообщение, что тот или иной индекс не правильный, и типа пересоздайте его 
REINDEX, т.е. то что могут сделать сотрудники сами, не помогает 
Помогает, только удаление и создание заного индекса, непосредственно из среды фокса ..... А так как сделать это могу только я сам , то не очень удобно ...
Очень похоже , что проблемма именно в 8-ых базах данных, ну не хотят они нормально работать под 9-кой. Теперь сам вопрос: Существует ли, какаяни-то конвертация именно БД 8-ого в 9-ый, очень уж не хотится ездить по всем филиалам и стучать мышью одну и туже композицию [i][small][color=Gray]Отредактировано (09.08.04 13:42) ------------------  |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Syberex Сообщений: 1432 Откуда: Кострома |
База из под VFP6 работает нормально!
В проге лучше не REINDEX делать, а определение индексов заново: INDEX ... INDEX ...  Придется сделать обновление, но стучать меньше... ------------------ |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Aleksey Tsingauz [MSFT] |
Цитата: Если речь идет об ошибке 2066, то индекс файл может быть на самом деле в порядке. Эта ошибка появляется в двух случаях: 1) Идекс файл действительно подпорчен. 2) Часть индекса, буферизированная в памяти VFP, сильно устарела и не стыкуется с тем, что подкачивается с диска (SET REFRESH слишком велико для той частоты, с которой другие приложения вносят изменения в индекс). Насколько я знаю, в VFP8 не выявленно проблем с построением индексов, которые привели бы к ошибке 2066. Вероятнее всего вы имеете дело со случаем (2). VFP8 и VFP9 генерируют ошибку 2066 при одних и тех же условиях. Причиной разницы в поведении может быть разница в скорости выполнения тех или иных операций или разница в настройке среды (SET REFRESH, размер памяти разрешенный для использования под буферизацию, ...). Чтобы избежать такого рода ошибку можно сделать следующее: 1) Уменьшить SET REFRESH, VFP9 позволяет установить второй параметер значительно меньше секунды или заставить VFP всегда читать с диска. 2) Уменьшить refresh интервал только для определенной рабочей области CURSORSETPROP("Refresh"). 3) Периодически вызывать SYS(1104) для сброса буферов, в VFP9 добавлен второй параметр позволяющий сбросить буферы только для определенной рабочей области. Aleksey Tsingauz Visual FoxPro Dev Team |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
John Koziol [MSFT] |
Aleksey is on vacation and shouldn't be answering technical posts. We want him to return well-rested
melnik писал(а): Цитата: |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Igor Korolyov Сообщений: 34066 |
Алексей, а как насчёт ситуации с порчей индекса (того что в памяти) при
выполнении такого вот примера: *SET STEP ON CLEAR SET ESCAPE ON SET MULTILOCKS ON SET EXCLUSIVE OFF SET REPROCESS TO 3 CREATE TABLE test1 (nSome I) INDEX ON nSome TAG nSome INSERT INTO test1 (nSome) VALUES (10) INSERT INTO test1 (nSome) VALUES (20) INSERT INTO test1 (nSome) VALUES (30) INSERT INTO test1 (nSome) VALUES (40) CLOSE TABLES ALL USE test1 SHARED ORDER nSome CURSORSETPROP("Buffering", 5, "test1") oAnother = CREATEOBJECT("VisualFoxpro.Application.9") m.oAnother.DefaultFilePath = SYS(5) + SYS(2003) m.oAnother.DoCmd("USE test1 SHARED ORDER nSome") m.oAnother.DoCmd("GO 2 IN test1") ? m.oAnother.Eval("RLOCK()") GO 2 IN test1 REPLACE nSome WITH 35 ? TABLEUPDATE(1, .F., "test1") ? AERROR(la1) DISPLAY MEMORY LIKE la1 LIST GO 2 IN test1 REPLACE nSome WITH 5 ? TABLEUPDATE(1, .F., "test1") ? AERROR(la1) DISPLAY MEMORY LIKE la1 LIST && Придётся прерывать по ESC ? "That's all" последовательность действий: 1 REPLACE Some WITH A 2 TABLEUPDATE() && Failed - блокировка в другой сессии 3 REPLACE Some WITH B 4 TABLEUPDATE() && Failed * После данной последовательности имеем "побитый индекс" - может вызывать Error 114 если попытаться далее работать с этим курсором. Данная проблема имеет место быть и в предыдущих версиях фокса - только AFAIR в VFP7 она ещё никак не ловилась (т.е. индекс слетал совершенно "молча"), а вот начиная с VFP8 уже начали генерится Error 114 при некоторых условиях... P.S. Вопрос обсуждался в FIDO7.RU.VISUAL.FOXPRO и на msnews.microsoft.com Newsgroups: microsoft.public.fox.helpwanted Subject: VFP 8 Index does not match the table Date: Tue, 2 Dec 2003 17:39:42 +0200 ------------------ WBR, Igor |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Равиль Сообщений: 6274 Откуда: Уфа |
Я тут натравил Сократа на пост от John Koziol [MSFT] (надо же какие люди к нам заглядывают) и понял, что "человек в отпуске и просьба не кантовать"Цитата:Подумалось, что если такая ситуация при явном RLOCK(), то почему бы такому не случаться и при параллельных TableUpdate() - ведь там те же блокировки, только неявные. Может не надо допускать, чтобы 2 пользователя одновременно сбрасывали буфер, а разводить их по семафору, например блокируя запись в служебной таблице - точнее я так делаю в последнее время и проблем стало меньше. Но все-равно иногда возникают ошибки (108 и чаще 109), такое впечатление, что после сброса буфера на некоторое время остаются какие-то блокировки, возможно индексных файлов. ------------------ Тяжело согнать курсором муху с монитора ... |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Syberex Сообщений: 1432 Откуда: Кострома |
Цитата: Я тоже!------------------ |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Igor Korolyov Сообщений: 34066 |
Ну дык когда писал ишшо был в неведении
Имеет место быть у меня сейчасзаметный лаг между написанием и отправкой письмеца А насчёт сути проблемы - да конечно ошибка блокировки может возникать и без явного "супердлинного RLOCK()" - это зависит от числа юзеров вносящих изменения и частоты этих изменений. Ну и ессно от SET REPROCESS - другое дело КАК обрабатывать такие ошибки. Я лично никогда и не пытался что-то там "поменять и попытаться снова" - но вот человек напоролся, и всплыло такое вот нехорошее поведение... А то как ты будешь его избегать (всякие ручные методы) - это всё несущественно IMHO - т.е. убегай не убегай, а проблема останется - просто перейдёт из одного места в другое, или выльется в общее снижение масштабируемости проги (т.е. ты предлагаешь делать эскалацию блокировок - вместо "позаписной" перейти на "потабличную" и даже на "многотабличную" - никогда не считал что это пойдёт на пользу стабильности проги)... В общем-то и так оно разрешимо - главное после такой ошибки не пытаться самому править данные, и блокировать UI от попыток юзера - т.е. оставить ему только "Отмениь и забыть", и "Попытаться ещё раз". ------------------ WBR, Igor |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата: А это будем исправлять. Спасибо. Aleksey Tsingauz Visual FoxPro Dev Team |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Igor Korolyov Сообщений: 34066 |
Похоже у вас отпуски столь же продолжительны и столь же отвлечены от работы
как и у нас   ------------------ WBR, Igor |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
Aleksey Tsingauz [MSFT] |
Цитата: Почему-то John решил подстраховать меня за два дня до окончания отпуска. |
||
| Re: Индексы 9-ки ......... | |||
|---|---|---|---|
|
melnik Автор Сообщений: 289 Откуда: г. Владимир |
Проблемма решилась , слегка далёким от фокса методом
Дело в том, что в большинстве филиалов у меня в качестве сервака стоит Linux с файл-серверным доступом. И жалобы поступали именно из линуксоидных отделений . С окнами подобных проблемм не возникало Ну я конечно обязал всех поставить масдайный сервер, и пока, тфу-тфу , в этом смысле всё работает на ура !!!!!!! |
||
| © 2000-2021 Fox Club |