|
|
|
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 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33823546&tid=1591286]: |
0ms |
get settings: |
6ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
149ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
91ms |
get tp. blocked users: |
2ms |
| others: | 216ms |
| total: | 506ms |

| 0 / 0 |
