|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
VFP 8.0 Видела когда-то похожий вопрос на этом форуме, но не помню, было ли решение, а поиском не нашла. Итак Делаю вьювер для просмотра данных по трем большим таблицам формата DBF. Таблицы подготавливаются заранее другими организациями и вносить в них изменения не то чтобы нельзя, но даже смысла не имеет. Первая таблица содержит паспортные данные льготников, вторая - инфу по льготам, а третья - реестр всех жителей города. Таблицы со льготами имеют примерно по 100тыс записей, третья - 3,5 млн записей. Льготы и льготники связываются по уникальному ключу. Льготники и жители связываются по сочетанию полей ФИО+Д/р. (смысл, короче, в том, что данных аахринеть много ^^). Обновление данных на машине пользователя производится простой заменой ДБФок - льготников ежедекадно, жители раз в квартал. Для связки используются неструктурные индексы. Собственно, наконец добралась до вопроса. При замене DBF хотелось бы, чтобы прога замечала эту замену и сама делала переиндексацию. Вариант с переиндексацией при запуске не покатит, т.к. даже на не самых слабых компах таблица с жителями индексируется 7-10 минут, а это чересчур долго, особенно если этот самый льготник стоит и ноет над душой оператора. Пока что нашла только такой кусочек кода Код: plaintext 1. 2. 3. 4. 5. 6.
Воть... Буду благодарна за все ссылки и советы, которые накидаете =^_^= ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 12:41 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Koryuu, при замене *.dbf надо убивать индексные файлы. При запуске программа должна проверять, существуют ли индексные файлы. Если да — открыть и работать дальше. Если нет — открыть, переиндексировать и работать дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 13:14 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Koryuu, сделайте запросы через select и можно обойтись без индексов. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 13:22 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Местами администратор, Запрос к таблице в три с половиной миллиона записей без индексов? Неудачный совет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 13:26 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Koryuu Обновление данных на машине пользователя производится простой заменой ДБФок - льготников ежедекадно, жители раз в квартал. Для связки используются неструктурные индексы. Собственно, наконец добралась до вопроса. При замене DBF хотелось бы, чтобы прога замечала эту замену и сама делала переиндексацию. С табличками работают, если я правильно понял, только на чтение. Тогда проверим, что дата индексного файла соответствует дате файла БД, если индекс старый перестроим его, иначе работаем в штатном режиме. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 13:49 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
авторПри замене DBF хотелось бы, чтобы прога замечала эту замену и сама делала переиндексацию. ну так в чем проблема? когда подменяете dbf затрите ф-лы cdx а в коде отклрытия таблиц у себя алгоритм: если нет индексных ф-лов то: index on ... tag ... index on ... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2010, 14:29 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Нашла неплохое решение на http://fox.wikis.com/wc.dll?Wiki~PersistentIndexCorruption, немного доработала напильником для себя и вот: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
При сравнении двух строк Ё>Я, а при сортировке Ё стоит раньше Я, а учитывая, что кодовая страница означенной таблицы 866, индексное выражение вообще пришлось зверски извратить. Вместо выражения fam-imya-otch сделала chrtran(fam-imya-otch,CHR(240)+CHR(168),CHR(133)+CHR(197)). Костыль, конечно, но работает ) Еще один минус такой проверки - на той самой трехмиллионной базе длится уж очень долго. Скорее всего, из-за составного индекса. Поэтому добавила в скан проверку Код: plaintext 1. 2. 3.
Надеюсь, кому-нибудь пригодится =^_^= ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2010, 13:12 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
KoryuuНашла неплохое решение на http://fox.wikis.com/wc.dll?Wiki~PersistentIndexCorruption, немного доработала напильником для себя и вот: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
При сравнении двух строк Ё>Я, а при сортировке Ё стоит раньше Я, а учитывая, что кодовая страница означенной таблицы 866, индексное выражение вообще пришлось зверски извратить. Вместо выражения fam-imya-otch сделала chrtran(fam-imya-otch,CHR(240)+CHR(168),CHR(133)+CHR(197)). Костыль, конечно, но работает ) Еще один минус такой проверки - на той самой трехмиллионной базе длится уж очень долго. Скорее всего, из-за составного индекса. Поэтому добавила в скан проверку Код: plaintext 1. 2. 3.
Надеюсь, кому-нибудь пригодится =^_^= А время полной переиндексации без проверок какое? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2010, 14:05 |
|
Определить, соответствует ли индекс таблице
|
|||
---|---|---|---|
#18+
Не, ну давайте уж без извращений :) Исходные данные - это одно, рабочая база - это другое. В любом случае вы должны работать на копии исходных данных, а не прямо на них, даже на чтение. У вас используются сторонние таблицы со своими индексами? - так импортируйте данные, когда их "приносят" (они "приходят"), и тогда же перестраивайте _свои_ индексы. Раз в декаду даже 10 минут никого не убьют. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2010, 20:37 |
|
|
start [/forum/topic.php?fid=41&fpage=103&tid=1585507]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 154ms |
0 / 0 |