powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Индексация в представлении
13 сообщений из 13, страница 1 из 1
Индексация в представлении
    #33625689
men dea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть буферизованная таблица с фамилиями, индексированная по алфавиту.
LV строится на ее основе. Порядок изначально алфавитный
Делаю Grid на базе этого LV.
Но при вводе-корректировке фамилий алфавитный порядок нарушается.
LV проиндексировать нельзя, т.к. оно в режиме буферизации.
А как сделать, чтобы алфавитный порядок не нарушался при изменениях?
Сбрасывать всякий раз все изменения в исходную таблицу и делать Requery() заново или что-то лучше есть?
...
Рейтинг: 0 / 0
Индексация в представлении
    #33625695
Фотография Владимир СА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
men deaЕсть буферизованная таблица с фамилиями, индексированная по алфавиту.
LV строится на ее основе. Порядок изначально алфавитный
Делаю Grid на базе этого LV.
Но при вводе-корректировке фамилий алфавитный порядок нарушается.
LV проиндексировать нельзя, т.к. оно в режиме буферизации.
А как сделать, чтобы алфавитный порядок не нарушался при изменениях?
Сбрасывать всякий раз все изменения в исходную таблицу и делать Requery() заново или что-то лучше есть?Еще разик почему: "LV проиндексировать нельзя, т.к. оно в режиме буферизации." ???
...
Рейтинг: 0 / 0
Индексация в представлении
    #33625743
karly™
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Local view нельзя проиндексировать при табличной буферизации (пятой). В режиме строковой (третьей) буферизации индексировать можно.

Можно сбросить изменения ( c помощью TableUpbate() или TableRevert() ), переключить буферризацию с табличной на строковую, проиндексировать, а потом снова включить табличную.
...
Рейтинг: 0 / 0
Индексация в представлении
    #33626137
men dea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При изменении буферизации 5 на 3, действительно, все индексируется. Но время от времени выскакивают ошибки.

Итак, есть таблица FIO (5 буф) с фамилиями (cFIO). По ней строится lvFIO (5 буф).
Строю Thisform.Grid c RecordSource='lvFIO'.

Пара ошибок такая:
1. Жму New: ввожу (непосредственно в Гриде) новую cFIO, напр. "Иванов". Запись устанавливается по алфавиту. Теперь корректирую ее на "Петров". Опять все по алфавиту.
2. Ввожу (New): "Сидоров". Она вводится прямо на "Петров" (ПОЧЕМУ?)
3. "Сидоров" остался, "Петров" исчез. (ПОЧЕМУ?)
4. Нажимаю Save. В Гриде оказываются "Сидоров" и "Иванов" (ПОЧЕМУ?)


В Thisform.Grid.Init() стоит:

Код: plaintext
1.
2.
3.
4.
Select lvFIO
CursorSetProp("Buffering", 3 ,'lvFIO')
Index  On cFIO Tag cfio
Set Order To cfio
CursorSetProp("Buffering", 5 ,'lvFIO')
В Thisform.Grid.grcCFIO.Text1.InterractiveChange() :

Код: plaintext
=Tableupdate(.f.,.t.,'lvFIO')

В Thisform.Grid.grcCFIO.Text1.Valid() :

Код: plaintext
1.
2.
3.
4.
If Empty(This.Value)
   This.Value='? Введи ФИО ?'
Endif
=Tableupdate(.f.,.t.,'lvFIO')	
Thisform.Grid.Refresh()
Теперь еще 4 кнопочки на форму:

New:
Код: plaintext
1.
2.
	Append Blank In lvFIO
	=Tableupdate(.F.,.T.,'lvFIO')
	Thisform.Grid.Refresh()
Delete:
Код: plaintext
1.
2.
3.
             Delete In lvFIO
             =Tableupdate(.F.,.T.,'lvFIO')
*    Вопрос: стоит ли здесь провести переиндексацию?
             Thisform.Grid.Refresh()
Cancel:
Код: plaintext
1.
2.
3.
4.
             =Tablerevert(.T.,'FIO')
              =Tablerevert(.T.,'lvFIO')
              Requery('lvFIO')
*    Вопрос: стоит ли здесь провести переиндексацию?
             Thisform.Grid.Refresh()
Save:
Код: plaintext
1.
2.
3.
4.
              =Tableupdate(.T.,.T.,'lvFIO')
              =Tableupdate(.T.,.T.,'FIO')
	Requery('lvFIO')
	Thisform.Grid.Refresh()
*   Вопрос: стоит ли здесь провести переиндексацию?

Что у меня не так? С индексным файлом или обработкой буферизации?
...
Рейтинг: 0 / 0
Индексация в представлении
    #33626668
men dea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Посмотрел по шагам, что происходит:
Вводится новая запись в представление lvFIO. Контролирую lvFIO через BROWSE: появилась. Появилась новая запись и в таблице FIO.
Разница состоит в том, автоинкрементное поле idFIO новой записи в таблице FIO обрело следующее AutoInc-значение, а в lvFIO равно 0. Если я насильно, через BROWSE внесу коррективу в кодовое поле в представлении, то дальше все работает корректно.

Но если, не внося в lvFIO указанную коррективу в кодовое поле, попробовать изменить в любое другое поле представления (напр.cFIO), то, видимо, сам VFP тут же помечает всю запись в представлении на удаление, хотя изменения в это "любое другое поле" вносит. А вот в таблице FIO изменения уже не проявляются. Видимо, из-за того, что запись в представлении уже помечена на удаление.

А если не вношу новую запись, а просто корректирую любую существующую, то изменения синхронно проявляются и в lvFIO и FIO.

И почему так все работает? Кодовое поле AutoInc тому виной?
И как выкрутиться? Запрашивать next-значение через GETAUTOINCVALUE() и сразу вносить его в кодовое поле новой записи представления?
...
Рейтинг: 0 / 0
Индексация в представлении
    #33629634
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чтение данных происходит по схеме

Исходная таблица - Local View

Сброс данных происходит по схеме

Буфер Local View - Local View - буфер исходной таблицы - исходная таблица.


Команда TableUpdate() - это команда сбоса буфера. Она ничего не читает из исходной таблицы.

Это значит, что если ты создашь в Local View 2 записи подряд, то получишь 2 записи со значение ключа 0. Именно потому, что Local View "не в курсе" относительно того, что исходная таблица уже была изменена.

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

Создал новую запись, дал команду TableUpdate(), в самом Local View код записи по прежнему 0, но буфера уже нет. Т.е. с точки зрения Local View - это уже запись, которая физически существует в таблице и имеет код записи равный 0. При модификации данных и последующей команде TableUpdate() ты должен бы был получить сообщение об ошибке, что записи с кодом 0 не существует.

Как это можно обойти с полем типа AutoIncrement?

Да, надо использовать GETAUTOINCVALUE(). Т.е. после создания новой записи вручную корректировать значение ключа непосредственно в Local View
...
Рейтинг: 0 / 0
Индексация в представлении
    #33635429
men dea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно, а поддерживается ли индексации при 5-й буферизации? Если при 5-й нельзя проиндексировать, не переходя в 3-ю, то при любых изменениях в индексном выражении придется вновь нырять в третью или все-таки изменение только в текущей будет отражено, т.к. это происходит только с одной записью?
...
Рейтинг: 0 / 0
Индексация в представлении
    #33635438
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А самому попробовать?
...
Рейтинг: 0 / 0
Индексация в представлении
    #33635802
men dea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А я и так попробовал. Вроде, индексация поддерживается, записи упорядочивались , хотя по логике 5-й буферизации не должны были. Но потом поползли ошибки. Причину не сумел понять: может из-за индексации, может еще по причине какого-нибудь иного моего незнания? Поэтому и задал вопрос.
Правда намучившись с этой индексацией, я упростил саму программку, выкинув лишний сервис, и данный вопрос из разряда "актуальный" перешел в "хотелось бы знать" :)

Правда, я с нетерпением жду от вас, В.М., ответа на другой вопрос в этом форуме с темой "Requery()".
...
Рейтинг: 0 / 0
Индексация в представлении
    #33635996
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Буферизация - это вовсе не исключительная собственность Local View. Это штатный механизм FoxPro. Ведь у Вас не возникает вопроса, поддерживается ли индекс в постоянных таблицах в некоем режиме буеризации. А Local View, по сути, и есть таблица. Правда, временная.
...
Рейтинг: 0 / 0
Индексация в представлении
    #33639733
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi men dea!

Есть некоторые ошибки работы с индексами для буферизованных таблиц - которые
правда возникают при строго определённых условиях, и которые вполне можно
избежать - ну например одна из наиболее часто встречающихся - попытка после
неудачного Tableupdate() ИЗМЕНИТЬ некоторые индексированные поля в той-же
самой записи, и снова сохранить её. Это приводит к "порче" индекса хранимого
в памяти фокса - в зависимости от версии фокса может генерироваться
соответствующая ошибка, либо ошибки не будет, но работа с таким некорректным
индексом будет приводить к массе других ошибок - типа "зацикливания"
SCAN-ов, или "двоения" записей, или "пропуска" целых диапазонов записей...
Причём как справедливо заметил Владимир разницы между постоянной DBF с
наложенной буферизацией и между View в этом отношении нет.
Вот где ЕСТЬ разница - так это в создании индексов и REQUERY() - по сути
REQUERY() пересоздаёт временную таблицу, и поэтому индексы созданные ДО
первого перезапроса и ПОСЛЕ него будут неравнозначны - первые всегда
останутся структурными (несмотря на то что JUSTSTEM(CDX()) и JUSTSTEM(DBF())
будут различны!) а последующие станут неструктурными (даже учитывая что для
некоторых из них JUSTSTEM(CDX())=JUSTSTEM(DBF())) - со всеми вытекающими
последствиями :(

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Индексация в представлении
    #33639793
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Igor Korolyov
Вот где ЕСТЬ разница - так это в создании индексов и REQUERY() - по сути
REQUERY() пересоздаёт временную таблицу, и поэтому индексы созданные ДО
первого перезапроса и ПОСЛЕ него будут неравнозначны - первые всегда
останутся структурными (несмотря на то что JUSTSTEM(CDX()) и JUSTSTEM(DBF())
будут различны!) а последующие станут неструктурными (даже учитывая что для
некоторых из них JUSTSTEM(CDX())=JUSTSTEM(DBF())) - со всеми вытекающими
последствиями :(
В VFP9 этот глюк исправлен.

Т.е. после Requery() получим JUSTSTEM(CDX())#JUSTSTEM(DBF()), но новый индекс создаваться не будет. Новые тэги будут создаваться в ранее созданном структурном индексном файле. CDX(2) останется пустым.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
USE MyView
INDEX ON Field1 TAG Field1
?"DBF() =",DBF()
?"CDX(1)=",CDX( 1 )
?"CDX(2)=",CDX( 2 )
Requery()
INDEX ON Field2 TAG Field2
?"DBF() =",DBF()
?"CDX(1)=",CDX( 1 )
?"CDX(2)=",CDX( 2 )

ДО VFP9 после Requery() получим 2 индексных файла. Что есть ошибка. В VFP9 останется по прежнему один. Что правильно.
...
Рейтинг: 0 / 0
Индексация в представлении
    #33642342
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi Владимир!

Спасибо, не знал что пофиксили :) Как-то на автомае старый код работает - а
он просто перед сохранением (поскольку там используется транзакция)
закрывает все неструктурные индексы через
SET ORDER TO
CLOSE INDEXES
(внутри try блока игнорирующего потенциальные ошибки)
и всё...

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Индексация в представлении
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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