|
|
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Hi alles Значит хочу записать мусор в одно из полей перед удалением Появилась проблема если я делаю Replace потом Delete и затем TableUpdate в transaction то replace не updat'ится только удаляется запись тогда я сделал 2 транзакции. Вопрос можно так делать или как заставить до первого tableupdate сделать и Replace и Delete. Спасибо! Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 12:01 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Что-то ты не договариваешь Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 12:33 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Hi PaulWist ты повторил мой первый вариант :) но он мне не нравится мне и мой последний вариант не нравится так как при падении delete внутри транзакции иногда вылетает ошибка "нельзя делать внутри транзакции..." Я бы хотел replace и delete сделать и выполнить всего один TableUpdate Что никак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 13:09 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
SET DELETED ON ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 13:12 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Тогда напиши внятно, что хочешь получить, если вложенные транзакции не нравятся. Если просто записать мусор и удалить, то Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 13:23 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Дело вовсе на в трпнзакциях у меня какой-то косяк во View пишу в command replace num1 with "TT" Delete все нормально TAbleupdate(.T.) REQUERY() и у меня поле num1 возвращает значение до replace в чем дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 14:50 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Работает только в случае как я и говорил сначала REplace TAbleupdate(.T.) delete TAbleupdate(.T.) REquery() тогда все нормально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 14:59 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Sea.s2Дело вовсе на в трпнзакциях у меня какой-то косяк во View пишу в command replace num1 with "TT" Delete все нормально TAbleupdate(.T.) REQUERY() и у меня поле num1 возвращает значение до replace в чем дело? Посмотреть, что возвращает Tableupdate() и если .F., то вызвать ф-ию AERROR() и посмотреть на расшифровку ошибки, что-то типа Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 15:25 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
TAbleUpdate везде возвращает .T. Просто заменяет replace на oldval replace delete tableupdate(.T.) BROWSE показывает все нормально REQUERY() Замещает на старое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 15:29 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Кстати вот этот lcAlias - это алиас чего, таблицы или view, и какая буферизация стоит на таблице? Если схема такая, то надо Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 15:29 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Исходная таблица buffering 1 Разве надо буфферизовать исходные таблицы?, никогда итого неделаю НА View 5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 15:36 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Тем более TableUpdate(.T.) я делал два раза на View исходной вообще не трогал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 15:37 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Да, смотри-ка, какая особенность обновления view, действительно новое значение игнорируется, а выставляется только пометка на удаление. Даже затрудняюсь сказать глюк это или так и должно быть, совершенно разное поведение для таблицы и view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 16:01 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Так и не смог ито побороть одним TableUpdatom + еще одна странность: Имеется 2 формы с Private DataSession в первой создал структурный индекс INDEX on expr TAG TT Захожу в другую где делаю USE того же view in 0 Создаю другой структурный индекс INDEX on expr TAG TT1 выхожу из нее делаю USE in .. Опять в первой форме создаю индекс INDEX on expr TAG TT Но теперь создается неструктурный индекс хотя таже DS и теперь при удалении возникает ошибка закройте неструктурный индекс Хотя нигде TAG OF не использовал в чем дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 12:43 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Даже вот так До REQUERY() можно насоздавать хоть сколько структурных индексов после пойдут неструктурные Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 13:20 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Hi Sea! Поищи тут объяснения способов работы обновляемых представлений - тогда тебе станет понятно, почему не происходит никакой "замены" при удалении записей. Попросту нет такой SQL команды "заменить и удалить" - а из двух этих альтернатив фокс при сбросе буфера представления естественно выбирает более правильную - удаление. Также поищи обсуждение индексов по представлениям - это тоже было - да, после REQUERY() изменяется имя "подлежащего" dbf-а (точнее tmp) - и все вновь создаваемые индексы идут в "новый" cdx (одноименный новому tmp) - тем не менее "старый" cdx всё ещё существует и именно он остаётся структурным cdx-ом. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 02:11 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Igor KorolyovПопросту нет такой SQL команды "заменить и удалить" - а из двух этих альтернатив фокс при сбросе буфера представления естественно выбирает более правильную - удаление. Игорь, ты не прав, если бы такое поведение было как для буфф. таблицы так и для View, то такое предположение можно было бы принять, НО поведение для таблицы отличается от View. Для буфф. таблицы сбрасываются как изменения поля, так и пометка на удаление, а для View сбрасывается только пометка на удаление. Налицо, либо баг, либо недокументированная фича. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 09:03 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Нет. Это не глюк. Все как положено. View - это НЕ исходная таблица. Это еще одна ДРУГАЯ таблица. Чтобы изменения, сделанные во View попали в исходную таблицу, необходимо сделать ЗАПИСЬ в исходной таблице. По косвенным признакам, это делается через команды INSERT-SQL, UPDATE-SQL и DELETE-SQL. Т.е. по команде TableUpdate() выполняется одна из этих 3 команд применительно к текущей записи View. Но именно, что "одна из", а не несколько. А по постановке задачи Sea.s2 хочет, чтобы было дано несколько команд. Local View на это не рассчитан. В данном случае, придется делать 2 сброса буфера: Код: plaintext 1. 2. 3. На первый TableUpdate() пройдет обновление по команде UPDATE-SQL, а на второй TableUpdate() пройдет удаление записи по команде DELETE-SQL. Что, собственно, он и сделал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 11:44 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
ВладимирМ ВладимирМView - это НЕ исходная таблица. Это еще одна ДРУГАЯ таблица. Ну дык. ВладимирМЧтобы изменения, сделанные во View попали в исходную таблицу, необходимо сделать ЗАПИСЬ в исходной таблице. По косвенным признакам, это делается через команды INSERT-SQL, UPDATE-SQL и DELETE-SQL. Владимир, это всё правильно, только при сбросе буфера таблицы почему-то выполняются (по твоей классификации) ДВЕ команды (UPDATE and DELETE), а при сбросе из VIEW только ОДНА (DELETE), те явное нарушение описанной логики. ВладимирМТ.е. по команде TableUpdate() выполняется одна из этих 3 команд применительно к текущей записи View. Ткни носом в хелп где об этом написано. Пока вижу авторCommits changes made to a buffered row, a buffered table, cursor, or cursor adapter. ВладимирМНо именно, что "одна из", а не несколько. Здесь можно только строить предположения о приоритетах, какая команда выполняется сначала, ведь сброс буфера скорее всего основан на GETFLDSTATE() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 12:57 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
PaulWist ВладимирМЧтобы изменения, сделанные во View попали в исходную таблицу, необходимо сделать ЗАПИСЬ в исходной таблице. По косвенным признакам, это делается через команды INSERT-SQL, UPDATE-SQL и DELETE-SQL. Владимир, это всё правильно, только при сбросе буфера таблицы почему-то выполняются (по твоей классификации) ДВЕ команды (UPDATE and DELETE), а при сбросе из VIEW только ОДНА (DELETE), те явное нарушение описанной логики. Почему ты решил, что буфер - это тоже таблица? Или о каком буфере идет речь? Чтение данных идет по цепочке Исходная таблица - Local View Запись данных идет по цепочке Буфер Local View - Local View - буфер исходной таблицы - исходная таблица Перенос информации из буфера в исходную таблицу осуществляется каким-то другими механизмами. То, что описал я - это перенос данных между таблицами. А что такое буфер - не в курсе. Какой механизм сброса буфера - понятия не имею. PaulWist ВладимирМТ.е. по команде TableUpdate() выполняется одна из этих 3 команд применительно к текущей записи View. Ткни носом в хелп где об этом написано. Пока вижу авторCommits changes made to a buffered row, a buffered table, cursor, or cursor adapter. Ты путаешь понятия. Я описал перенос данных не из буфера, а между двумя таблицами, поскольку Local View - это однозначно таблица. Вот я и описал перенос данных из одной таблицы в другую. Из Local View в исходную таблицу. Косвенных ссылок на то, что этот сброс осуществояется SQL-командами в HELP - полно. Но я не знаю ни одной SQL команды, которая одновременно выполняла бы 2 действия - модификацию и удаление. PaulWist ВладимирМНо именно, что "одна из", а не несколько. Здесь можно только строить предположения о приоритетах, какая команда выполняется сначала, ведь сброс буфера скорее всего основан на GETFLDSTATE() Опять. Речь не о буфере, а о взаимодействии таблиц. Тут команда TableUpdate() вводит в заблуждение, поскольку применительно к Local View она выполняет 2 действия: сбрасывает собственно буфер Local View в сам Local View (тут все в порядке), а затем переносит изменения сделанные в Local View в исходную таблицу. И вот на этом этапе и срабатывают все те механизмы команд SQL о которых я написал выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 13:14 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
ВладимирМ Что бы нам не спорить о понятиях, выполни тест и прокоментируй. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 13:58 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Комментирую 1) "Голая таблица" Работаем только с буфером таблицы. Все изменения по команде TableUpdate() переносятся из буфера в исходную таблицу. Причем сначала переносится метка на удаление и только потом модификация. Как я это узнал. Поставил в триггерах таблицы .F. после того, как TableUpdate() вернул .F. посмотрел значение 5 элемента массива полученного по AERROR(). Там стояла 3. Т.е. сработал триггер на удаление. 2) Local View По команде TableUpdate() происходит 2 события: -) Сброс буфера Local View в собственно Local View -) Перенос изменений сделанных в Local View в исходную таблицу. Заметь, здесь речь уже вообще не идет о буферах. Это просто обновление данных в одной таблице данными из другой. Хотя порядок этих двух операций скорее всего обратный: сначала перенос из буфера Local View в исходную таблицу, а потом сброс буфера самого Local View. Перед переносом вполне логично делается анализ на тип выполняемого изменения. Сначала делается анализ на факт удаления. Имеет место быть. Вот и выполняем удаление. А вот следующего шага на модификацию уже удаленной записи не делается, что вполне логично. Какой смысл изменять не существующую запись? Вообще-то, с точки зрения контейнера базы данных, записи помеченной как удаленная уже не существует. "Умерла так умерла". На ней не работают триггера на модификацию. Попробуй в созданном Local View создать новую запись и тут же ее удалить. При сбросе буфера в исходной таблице новой удаленной записи не появится. Однако если то же самое сделать на самой таблице, то новая удаленная запись появится. Разные механизмы работают при "простом" сбросе буфера и при переносе изменений из Local View в таблицу источник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 19:39 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
ВладимирМКомментирую 1) "Голая таблица" Работаем только с буфером таблицы. Все изменения по команде TableUpdate() переносятся из буфера в исходную таблицу. Причем сначала переносится метка на удаление и только потом модификация. Ну, что же, ты подтвердил мои предыдущие слова PaulWistДля буфф. таблицы сбрасываются как изменения поля, так и пометка на удаление, а для View сбрасывается только пометка на удаление. ВладимирМ2) Local View ....... Перед переносом вполне логично делается анализ на тип выполняемого изменения. Сначала делается анализ на факт удаления. Имеет место быть. Вот и выполняем удаление. А вот следующего шага на модификацию уже удаленной записи не делается, что вполне логично. Какой смысл изменять не существующую запись? Вот это-то и удивило автора топика, для таблицы делаем replace-delete, получаем все изменения в таблице, он ожидал такого же поведения и для View, ан нет "облом-с". Поэтому было написано PaulWistДа, смотри-ка, какая особенность обновления view, действительно новое значение игнорируется, а выставляется только пометка на удаление. Даже затрудняюсь сказать глюк это или так и должно быть, совершенно разное поведение для таблицы и view Ну и твоё заключение ВладимирМрРазные механизмы работают при "простом" сбросе буфера и при переносе изменений из Local View в таблицу источник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:05 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Что-то не получается переоткрыть структурный индекс и уничтожить неструктурный перед удалением Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. После requery() неструктурного индекса нет структурный виден на диске но set index устанавливает связь на индекс исходной таблицы а стуктурный индекс view не видит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 12:34 |
|
||
|
Replace, Delete in Transaction
|
|||
|---|---|---|---|
|
#18+
Вот это что за бред выполняю код без DELETE все проходит без ошибки С DELETE проподает структурный индекс view и связь уходит на индекс исходной таблицы и соответсвенно вылетает ошибка TAG индекса не найден у меня уже голова идет кругом от итих заморочек ну в чем тут дело Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 08:22 |
|
||
|
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?all=1&fid=41&tid=1591286]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 327ms |

| 0 / 0 |
