Hi sar99!

1) Не нужно кричать :)
2) Что есть * НЕКОТОРЫЕ ДЕЙСТВИЯ ПО ОБНОВЛЕНИЮ ДРУГОЙ ТАБЛИЦЫ
3) Есть ли где-то код перезапроса данных? каковы настройки Conenction и RS? Есть ли такие-же проблемы если работать через ODBC? Пробовал ли использовать другие Ole DB провайдеры? Возникает ли проблема если просто работать с таким курсором (без всяких гридов, из командного окна например).

Posted via ActualForum NNTP Server 1.1

Hi sar99!

А без грида - в собственно курсоре эта запись есть?
Есть ли она в "нижележащем" RS?
Есть ли индексы на курсор? Если есть, то попробуй их все убрать временно.
Что значит "в некоторых случаях" - конкретнее скажи что за случаи - т.е. что влияет на возникновение проблемы.

P.S. На 99% уверен что то что IB "версионник" никакого отношения к проблеме не имеет - всё-же дело скорее всего где-то на стыке ADO/CA и возможно грида как такового...
Попробуй "отключать" грид от привязанного курсора перед операцией (ну это известный приём - сохранить RecordSource грида и ControlSource колонок - потом "занулить" RecordSource - сделать что нужно и восстановить всё обратно). Если проблема на стыке грид/курсор то должно помочь - но если фантомная запись всё-же имеется в курсоре - то надо другое смотреть...

Posted via ActualForum NNTP Server 1.1

Hi sar99!

> В курсоре фантомная запись есть - просматривается BROW

Понятно.

> в низлежащем RS трудно проверить(только разве DATAGRID подключить)

Просто "походить" по нему навигационными методами, выводя какое-нить уникальное поле.

> Что касается отдельных случаев появления то у меня в этом
> же проекте в этом же подключении есть еще одно окно
> с 100% похожим кодом корректировки другой таблицы -
> там фантомной записи не возникает!

А индексы там тоже есть?

> пробовал отключить индекс - не помогает

В смысле ВООБЩЕ его не создавать - НИКОГДА - ни до заполнения, ни после перезапроса...

> пробовал отключить транзакцию - не помогает.

В смысле вообще отказаться от транзакций?

> я склонен думать что дело в версионности

Блин, ну не знает ничего CA ни про какую версионность! И сколько работаю с Oracle (который тоже по сути версионник) - никогда таких проблем не возникало. Вот в кривости конкретного OLE DB может быть дело. В слёте индекса ОЧЕНЬ может быть дело (симптомы уж сильно похожи на слетевший индекс)

> фантом не автономен и при удалении основной записи исчезает.

При удалении записи перестраивается индекс - и есть именно там был "дубляж", то очевидно он исчезнет. А индекс (на курсор в т.ч.) очень легко слетает при неаккуратной работе - например поменять поле, дать TableUpdate() который по какой-либо причине не сработает (триггер отфутболит или ещё чего-то), потом НЕ давая Tablerevert снова поменять поле и снова дать TableUpdate - всё - порча индекса произошла (причём именно индекса в памяти!)

Posted via ActualForum NNTP Server 1.1

Hi sar99!

И что по твоему делает Tablerevert() и чем он будет отличаться от Tablerevert(.T.,"MyAlias")? Я предпочитаю всегда ЯВНО указывать такие параметры. Кроме того я не видел где у тебя меняется (и меняется ли вообще!) режим буферизации. Т.к.
1) В табличном режиме нельзя создать индекс
2) В строковом режиме практически невозможно работать в гриде - всякое перемещение по строкам вызывает неявные попытки сброса буфера.

Кстати я не в курсе как пройдёт tablerevert() в контексте открытой транзакции (пускай и ADO-шной). IMHO есть смысл (даже если проблема и не в этом) поменять местами откат транзакции и Rollback? Или поступить ещё более кардинально - уничтожить все индексы ПЕРЕД сбросом изменений и восстановить после...

Posted via ActualForum NNTP Server 1.1

Hi sar99!

Ты не понял... Попробую попроще:
Буферизация строк#буферизации таблицы! И для работы с гридом практически ВСЕГДА лучше использовать именно последнюю! т.е. 5-ю
TABLEREVERT() делает откат только в ОДНОЙ записи - в текущей - равно как и TABLEUPDATE(). Почему я и намекал тебе на пропущенные параметры этих функций.
КУРСОР (в т.ч. создаваемый CA) - это ВСЕГДА локальная временная таблица - и потому никаких вопросов с "многопользовательским" доступом нет и быть не может - индекс же нужно делать именно CDX причём структурным! на foxclub.ru есть решение проблемы, возникающей после REQUERY() - когда меняется DBF() - и "вновь создаваемые" индексы перестают быть структурными. Это важно при использовании фоксовых транзакций.
И транзакцию следует делать двойную! И фоксовую И ADO-шную. Иначе что получаем - в фоксе транзакции нету - значит те записи которые CA нормально сохранил, фокс пометил в курсоре как "без изменений" - тут он наткнулся на ту запись, которую сохранить не может - и процесс прервался - при этом ADO-ную транзакцию он откатил -> те записи что у нас в курсоре помечены как "неизменные" реально рассинхронизированы с ADO-шными!!! там то они к Oldval вернулись (или их вовсе нет если это "вставленные" записи были)!
То какое поле меняется - не суть важно. Главное что индекс каким-то образом активен в данный момент (использован явно по SET ORDER, или неявно Rushmore движком)...
В общем вопросов к твоему коду ещё много - приведи его немного в порядок, разберись с особенностями Row и Table-буферизации, с особенностями курсоров vs tables (в части индексирования и совместного доступа например)... Уточни во всех функциях параметры.

Posted via ActualForum NNTP Server 1.1

Hi sar99!

1) Транзакции работают и для SPT/CA-курсоров - попробуй просто из командного окна BEGIN TRANSACTION - потом поменять данные в курсоре, и дать ROLLBACK. Из-за этого есть хороший шанс нарваться на конфликт, при несогласованных транзакциях. БЕЗ фоксовой транзакции твой серверный ROLLBACK отменит все изменения которые УЖЕ были сброшены из буфера, а вот в курсоре они будут помечены как "сохранённые" - лишь начиная с "неудачно сохранённой" записи курсор будет "правильным" - т.е. соответствовать тому что есть на сервере (в части OLDVAL() по которой и строится в частности WHERE часть команд обновления). И соответственно при следующей попытке сохранения, если эти якобы "удачно сохранённые" были изменены, их просто не найдёт сервер - ибо будет искать по тем данным ,который были откинуты транзакцией. Решить это можно либо введя дополнительно фоксовую транзакцию, либо делая перезапрос данных после каждой такой неудачи (ессно это вызовет потерю всех несохранённых изменений - хотя возможно что хватило бы исправления одного символа, чтобы сохранение прошло нормально).

2) Понятия не имею что у тебя за проблемы с индексом. У меня всегда всё работало нормально, причём индексы вообще создавались динамически ("на лету"), и порой их было столько-же сколько и полей отображалось в гриде. Очевидно ты что-то недопонял в части настроек WhereType, KeyFieldList и вообще того КАК фокс генерирует UPDATE/DELETE команды, и почему это вызывает "конфликт обновления". Поставь вывод SQL кода (параметра метода) в обработчики BeforeInsert\Update\Delete и посмотри что и как делает фокс.

3) В версиях ДО VFP9 к сожалению есть проблема - несовместимость с varchar типами данных - фокс то их дополняет пробелами! А потом сервер и попадает в тупик - для него "что-то____" # "что-то" (вместо хвостовых пробелов я нарисовал подчёркивание, чтоб было понятнее). Соответственно созданная CA или RV команда, например UPDATE ... SET ... WHERE nPK = OLDVAL("Cursor.nPK") AND VarCharField = OLDVAL("Cursor.VFPFixedLengthField") показывает "конфликт совместного доступа". От наличия/отсутствия индекса это никак не зависит. Единственный способ побороть - это убрать Varchar поля из WHERE части запроса - это можно сделать либо выставив WhereType в "KeyFieldsOnly", либо явно указывая при TableUpdate() второй параметр .T. - это равносильно (но только WhereType ВСЕГДА работает, а параметр можно и менять по ходу дела)...

Posted via ActualForum NNTP Server 1.1

Hi sar99!

> То что для СА поддерживаются транзакции FOXPRO для меня
> новость (пока не проверил!!!) Если да , то естественно надо
> применять пару - фоксовскую и серверную.

Не CA, а любой буферизованный курсор. менно в плане работы буфера и сказываются эти особенности (учитывая что "постоянного места жительства" данные в курсоре не имеют).

> Два вопроса (возможно я действительно не разобрался
> с KeyFieldList и WhereType):
> 1. если в СА первичный ключ составной (key_id,dezn)
> то указывать при создании СА
> KeyFieldList = key_id,dezn ?

Да.

> 2 В документации возможные значения WhereType (1,2,3,4)
> какое значение нужно установить , чтобы не было проблемм
> с полями типа VARCHAR ?

1 и 4 (если сможет источник данных!) - но это не даст тебе возможности отслеживать конфликты совместного доступа. Как вариент (именно для CA) - использовать ConversionFunc (читай хелп!). Конечно я предполагаю что среди ключевых полей точно нету Var* полей (т.е. полей с переменной длинной записи) :)
Я не в курсе как оно взаимодействует с ADO (не использовал такую связку) - там всё-же несколько иной механизм, но есть подозрение что и там могут быть проблемы с лишними пробелами... Ну и конечно всегда можно всё переделать на "ручные" команды обновления - благо возможность такая штатно имеется.

Posted via ActualForum NNTP Server 1.1