|
|
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Есть буферизованная таблица с фамилиями, индексированная по алфавиту. LV строится на ее основе. Порядок изначально алфавитный Делаю Grid на базе этого LV. Но при вводе-корректировке фамилий алфавитный порядок нарушается. LV проиндексировать нельзя, т.к. оно в режиме буферизации. А как сделать, чтобы алфавитный порядок не нарушался при изменениях? Сбрасывать всякий раз все изменения в исходную таблицу и делать Requery() заново или что-то лучше есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2006, 13:38 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
men deaЕсть буферизованная таблица с фамилиями, индексированная по алфавиту. LV строится на ее основе. Порядок изначально алфавитный Делаю Grid на базе этого LV. Но при вводе-корректировке фамилий алфавитный порядок нарушается. LV проиндексировать нельзя, т.к. оно в режиме буферизации. А как сделать, чтобы алфавитный порядок не нарушался при изменениях? Сбрасывать всякий раз все изменения в исходную таблицу и делать Requery() заново или что-то лучше есть?Еще разик почему: "LV проиндексировать нельзя, т.к. оно в режиме буферизации." ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2006, 13:54 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Local view нельзя проиндексировать при табличной буферизации (пятой). В режиме строковой (третьей) буферизации индексировать можно. Можно сбросить изменения ( c помощью TableUpbate() или TableRevert() ), переключить буферризацию с табличной на строковую, проиндексировать, а потом снова включить табличную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2006, 15:17 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
При изменении буферизации 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. Код: plaintext В Thisform.Grid.grcCFIO.Text1.Valid() : Код: plaintext 1. 2. 3. 4. New: Код: plaintext 1. 2. Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. Что у меня не так? С индексным файлом или обработкой буферизации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2006, 03:02 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Посмотрел по шагам, что происходит: Вводится новая запись в представление lvFIO. Контролирую lvFIO через BROWSE: появилась. Появилась новая запись и в таблице FIO. Разница состоит в том, автоинкрементное поле idFIO новой записи в таблице FIO обрело следующее AutoInc-значение, а в lvFIO равно 0. Если я насильно, через BROWSE внесу коррективу в кодовое поле в представлении, то дальше все работает корректно. Но если, не внося в lvFIO указанную коррективу в кодовое поле, попробовать изменить в любое другое поле представления (напр.cFIO), то, видимо, сам VFP тут же помечает всю запись в представлении на удаление, хотя изменения в это "любое другое поле" вносит. А вот в таблице FIO изменения уже не проявляются. Видимо, из-за того, что запись в представлении уже помечена на удаление. А если не вношу новую запись, а просто корректирую любую существующую, то изменения синхронно проявляются и в lvFIO и FIO. И почему так все работает? Кодовое поле AutoInc тому виной? И как выкрутиться? Запрашивать next-значение через GETAUTOINCVALUE() и сразу вносить его в кодовое поле новой записи представления? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2006, 11:35 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Чтение данных происходит по схеме Исходная таблица - 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:03 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Интересно, а поддерживается ли индексации при 5-й буферизации? Если при 5-й нельзя проиндексировать, не переходя в 3-ю, то при любых изменениях в индексном выражении придется вновь нырять в третью или все-таки изменение только в текущей будет отражено, т.к. это происходит только с одной записью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:26 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
А самому попробовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:28 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
А я и так попробовал. Вроде, индексация поддерживается, записи упорядочивались , хотя по логике 5-й буферизации не должны были. Но потом поползли ошибки. Причину не сумел понять: может из-за индексации, может еще по причине какого-нибудь иного моего незнания? Поэтому и задал вопрос. Правда намучившись с этой индексацией, я упростил саму программку, выкинув лишний сервис, и данный вопрос из разряда "актуальный" перешел в "хотелось бы знать" :) Правда, я с нетерпением жду от вас, В.М., ответа на другой вопрос в этом форуме с темой "Requery()". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 17:01 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Буферизация - это вовсе не исключительная собственность Local View. Это штатный механизм FoxPro. Ведь у Вас не возникает вопроса, поддерживается ли индекс в постоянных таблицах в некоем режиме буеризации. А Local View, по сути, и есть таблица. Правда, временная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 18:01 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Hi men dea! Есть некоторые ошибки работы с индексами для буферизованных таблиц - которые правда возникают при строго определённых условиях, и которые вполне можно избежать - ну например одна из наиболее часто встречающихся - попытка после неудачного Tableupdate() ИЗМЕНИТЬ некоторые индексированные поля в той-же самой записи, и снова сохранить её. Это приводит к "порче" индекса хранимого в памяти фокса - в зависимости от версии фокса может генерироваться соответствующая ошибка, либо ошибки не будет, но работа с таким некорректным индексом будет приводить к массе других ошибок - типа "зацикливания" SCAN-ов, или "двоения" записей, или "пропуска" целых диапазонов записей... Причём как справедливо заметил Владимир разницы между постоянной DBF с наложенной буферизацией и между View в этом отношении нет. Вот где ЕСТЬ разница - так это в создании индексов и REQUERY() - по сути REQUERY() пересоздаёт временную таблицу, и поэтому индексы созданные ДО первого перезапроса и ПОСЛЕ него будут неравнозначны - первые всегда останутся структурными (несмотря на то что JUSTSTEM(CDX()) и JUSTSTEM(DBF()) будут различны!) а последующие станут неструктурными (даже учитывая что для некоторых из них JUSTSTEM(CDX())=JUSTSTEM(DBF())) - со всеми вытекающими последствиями :( Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 16:35 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
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. ДО VFP9 после Requery() получим 2 индексных файла. Что есть ошибка. В VFP9 останется по прежнему один. Что правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 18:35 |
|
||
|
Индексация в представлении
|
|||
|---|---|---|---|
|
#18+
Hi Владимир! Спасибо, не знал что пофиксили :) Как-то на автомае старый код работает - а он просто перед сохранением (поскольку там используется транзакция) закрывает все неструктурные индексы через SET ORDER TO CLOSE INDEXES (внутри try блока игнорирующего потенциальные ошибки) и всё... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 02:34 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33635429&tid=1591988]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
191ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 217ms |
| total: | 503ms |

| 0 / 0 |
