powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Replace, Delete in Transaction
7 сообщений из 32, страница 2 из 2
Replace, Delete in Transaction
    #33826492
Sea.s2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Мдее отследил ALIAS() он почему-то меняется после tableupdate на alias исходной
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
LOCAL lcIdx, lcOrder, lcDesc
  CURSORSETPROP("Buffering",  3 , ThisForm.Alias)
    m.lcOrder = ORDER(ThisForm.Alias)
    m.lcIdx   = SET("Index")
    m.lcIdx   = SUBSTR(lcIdx,  1 , AT(".cdx", lcIdx) +  3 )
    SET INDEX TO &lcidx
    IF !EMPTY(lcOrder) THEN
      SET ORDER TO TAG (lcOrder) ASCE
    ENDIF
  CURSORSETPROP("Buffering",  5 , ThisForm.Alias)
    
    BEGIN TRANSACTION
      MESSAGEBOX(ALIAS())  &&Alias view
      DELETE
      TABLEUPDATE(.F., .T., ThisForm.Alias)
      ROLLBACK
      &&SELECT (ThisForm.alias)  &&Ну и кто поменял область?? Триггер?
      MESSAGEBOX(ALIAS())  &&Alias исходной таблицы
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33827123
Sea.s2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Еще вопрос про индексы

Значит такая ситуация создается например 3 индекса для view
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
INDEX ON num1 TAG num1
INDEX ON num2 TAG num2
INDEX ON num1 + num2 TAG TotalTag

For i= 1  to  3 
  MessageBox(TAG(i))
endfor
Делаем перезапрос
REQUERY()

После requery создается неструктурный индекс с таким выражением что мы имеем?
Код: plaintext
1.
2.
3.
4.
INDEX ON num2 + num1 TAG TotalTag
For i= 1  to  4 
  MessageBox(TAG(i))
Endfor

Последнее два tag’a будут num1 + num2 и num2 + num1

Закрываю неструктурный индекс допустим перед удалением
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
LOCAL lcIdx, lcOrder, lcDesc
  CURSORSETPROP("Buffering",  3 , ThisForm.Alias)
    m.lcOrder = ORDER(ThisForm.Alias)
    m.lcIdx   = SET("Index")
    m.lcIdx   = SUBSTR(lcIdx,  1 , AT(".cdx", lcIdx) +  3 )
    CLOSE INDEXES
    SET INDEX TO &lcidx
    IF !EMPTY(lcOrder) THEN
      SET ORDER TO TAG (lcOrder) IN (ThisForm.Alias) &tcSort
    ENDIF
  CURSORSETPROP("Buffering",  5 , ThisForm.Alias)
Имеем

For i=1 to 3
MessageBox(TAG(i))
Endfor

Последнее tag будет num1 + num2

Т.е индекс (num2+num1) который я создавал будет замещен на самый первый TotalTag num1 + num2.
И единственна возможность его восстановить это постоянно как надо удалить пачку записей индексировать и индексировать по нему.
Что так и поступать?
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33827585
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33828968
Sea.s2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я и так создаю все индексы вначале но дело в том что при множественной сортировке все равно придется создавать в любое время индекс и после первого же REQUERY он пойдет в неструктурный

Удалять все теги я не могу у меня есть теги связанные 1:1 с некоторыми временными курсорами + вторая таблица на параметр where бывает

Единственный выход возможен это делать параметр во view на order by
или постоянно жить с неструктурным индексом и ждать подвоха и вставлять везде (код запоминия tega, закрытие неструктурного, снова индексация)
И во время удаления очень трудно будет предсказать куда уйдет указатель записи после изменения сортировки.

Параметр на order by вы Igor Korolyov мне месяц назад сказали не делать вот и начался итот гимор.
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33829368
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sea.s2Я и так создаю все индексы вначале но дело в том что при множественной сортировке все равно придется создавать в любое время индекс и после первого же REQUERY он пойдет в неструктурный
Он как раз останется структурным . Проверяется это через функцию

?CDX(1)

Т.е. стратегия следующая:

-) ДО начала молификации для View создается нужное количество тэгов структурного индекса. Просто командой INDEX ON ... TAG ... без указания имени файла

Код: plaintext
1.
2.
select MyView
INDEX ON MyField TAG MyField

-) Команда Requery() автоматически обновит содержимое этого структурного инедкса, при этом оставив его структурным . Ничего закрывать или удалять перед командой Requery() не надо.

Если возникает необходимость ПОСЛЕ команды Requery() создать еще один индекс, то в этом случае придется ЯВНО указать имя индексного файла

Код: plaintext
1.
2.
3.
4.
select MyView
LOCAL lcFileName
lcFileName = CDX( 1 )
INDEX ON MyField TAG MyField OF (m.lcFileName)

Надо указывать имя именно через CDX(1), поскольку, в версиях до VFP9, после Requery() имя структурного индекса отличается от имени файла.
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33829849
Sea.s2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я в шоке стольк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."

Больше ничего закрывать и переиндексовывать не надо все в одном структурном индексе фуууу...
Зато узнал всякие полезные вещи спасибо всем!!
...
Рейтинг: 0 / 0
Replace, Delete in Transaction
    #33831507
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
7 сообщений из 32, страница 2 из 2
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Replace, Delete in Transaction
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]