|
|
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Мдее отследил ALIAS() он почему-то меняется после tableupdate на alias исходной Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 09:02 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Еще вопрос про индексы Значит такая ситуация создается например 3 индекса для view Код: plaintext 1. 2. 3. 4. 5. 6. 7. REQUERY() После requery создается неструктурный индекс с таким выражением что мы имеем? Код: plaintext 1. 2. 3. 4. Последнее два tag’a будут num1 + num2 и num2 + num1 Закрываю неструктурный индекс допустим перед удалением Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. For i=1 to 3 MessageBox(TAG(i)) Endfor Последнее tag будет num1 + num2 Т.е индекс (num2+num1) который я создавал будет замещен на самый первый TotalTag num1 + num2. И единственна возможность его восстановить это постоянно как надо удалить пачку записей индексировать и индексировать по нему. Что так и поступать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 12:31 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Hi Sea! Наверное правильной стратегией в данном случае будет: 1) Создать СРАЗУ все необходимые индексы - т.е. после первого открытия представления - индексы все пойдут в структурный cdx - после перезапроса ничего делать не нужно - "старые" индексы автоматически перестраиваются (и текущий тег кстати остаётся текущим). 2) Перед перезапросом не просто снимать текущий тег, а явно удялять ВСЕ теги (при этом естественно удалится и соответствующий структурный cdx) - после перезапроса можно создавать новые теги - они пойдут в новый структурный cdx. Во втором варианте есть особенность - если удалять старые теги ПОСЛЕ перезапроса, то в VFP9SP1 становится невозможным создать новые структурные теги - он как-то некоректно удаляет/закрывает этот самый структурный cdx, и при очередном INDEX ON возникает ошибка 1113 File is not open. При этом вообще как-то хитро "портятся" внутренние фоксовые таблицы открытых файлов - т.е. "на пустом месте" начинают сыпаться те-же самые ошибки 1113 при обращении к другим dbf-ам или индексам... В общем ради собственного спокойствия лучше всё-же удалять теги ДО перезапроса... Будет время отпишу в MSFT про эту ошибку - может пофиксят в SP2. P.S. В VFP9SP1 поведение изменено - даже после перезапросов команда INDEX ON .... TAG ... (без явного указания cdx файла) тег создаётся не в новом "якобы-структурном" cdx (с именем "новго" tmp файла) а в старом cdx (который хоть и отличается по имени от нового tmp тем не менее является структурным и не мешает транзакциям). Но там есть баг описанный выше... P.P.S. Сомневаюсь что после перезапроса можно "прицеплять" заранее отцепленный cdx файл (ты его кстати так просто и не отцепишь - CLOSE INDEXES не поможет - т.к. тот cdx является по сути структурным, а их данная команда не отключает) - но даже если это и удастся то индекс в любом случае будет неверным - т.е. потребует выполнения REINDEX (т.к. после перезапроса весьма вероятно что соответствие между номерами записей в курсоре и значениями индексного ключа будут совершенно другими нежели ДО перезапроса). Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 14:17 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Я и так создаю все индексы вначале но дело в том что при множественной сортировке все равно придется создавать в любое время индекс и после первого же REQUERY он пойдет в неструктурный Удалять все теги я не могу у меня есть теги связанные 1:1 с некоторыми временными курсорами + вторая таблица на параметр where бывает Единственный выход возможен это делать параметр во view на order by или постоянно жить с неструктурным индексом и ждать подвоха и вставлять везде (код запоминия tega, закрытие неструктурного, снова индексация) И во время удаления очень трудно будет предсказать куда уйдет указатель записи после изменения сортировки. Параметр на order by вы Igor Korolyov мне месяц назад сказали не делать вот и начался итот гимор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2006, 07:08 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Sea.s2Я и так создаю все индексы вначале но дело в том что при множественной сортировке все равно придется создавать в любое время индекс и после первого же REQUERY он пойдет в неструктурный Он как раз останется структурным . Проверяется это через функцию ?CDX(1) Т.е. стратегия следующая: -) ДО начала молификации для View создается нужное количество тэгов структурного индекса. Просто командой INDEX ON ... TAG ... без указания имени файла Код: plaintext 1. 2. -) Команда Requery() автоматически обновит содержимое этого структурного инедкса, при этом оставив его структурным . Ничего закрывать или удалять перед командой Requery() не надо. Если возникает необходимость ПОСЛЕ команды Requery() создать еще один индекс, то в этом случае придется ЯВНО указать имя индексного файла Код: plaintext 1. 2. 3. 4. Надо указывать имя именно через CDX(1), поскольку, в версиях до VFP9, после Requery() имя структурного индекса отличается от имени файла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2006, 10:44 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Я в шоке столькo проблем ушло от прибавления слова OF (CDX(1, ThisForm.Alias)) Прошу у всех прощения, но я почему-то думал что TAG OF создает неструктурные TAG's и старательно итого избегал еще help смутил "If you exclude the optional OF CDXFileName clause from TAG TagName, you create a structural compound index file." Больше ничего закрывать и переиндексовывать не надо все в одном структурном индексе фуууу... Зато узнал всякие полезные вещи спасибо всем!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2006, 12:48 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Hi ВладимирМ! > Надо указывать имя именно через CDX(1), поскольку, в версиях до VFP9, > после Requery() имя структурного индекса отличается от имени файла. Скорее так: В версиях до VFP9 команда INDEX ON ... TAG ... (без указания OF имя_CDX) создаёт теги в cdx файле имеющем то-же самое имя что возвращает функция DBF() - при этом для представлений возникает неприятный эффект, связанный с тем, что после перезапроса индексный файл с именем = DBF() уже будет неструктурным! В VFP9 поведение изменено так, что INDEX ON ... TAG ... создаёт теги в структурном CDX, если таковой имеется - независимо от текущего значения DBF() для данного курсора. Если структурного CDX нет, то поведение конечно идентично. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 00:44 |
|
||
|
|

start [/forum/topic.php?fid=41&startmsg=33826492&tid=1591286]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
79ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 415ms |

| 0 / 0 |
