Всем привет!
ХОТЕЛОСЬ БЫ ОБСУДИТЬ СЛЕДУЮЩУЮ ПРОБЛЕММУ!!!
КАК ИЗВЕСТНО КУРСОР_АДАПТЕР - ЭТО ПРОМЕЖУТОЧНЫЙ КУРСОР
ДЛЯ РАБОТЫ VFP8 С ВНЕШНЕЙ БАЗОЙ. СЛЕДОВАТЕЛЬНО ТРАНЗАКЦИИ
VFP8 НЕ БУДУТ РАБОТАТЬ ДЛЯ ПРОЦЕССА ПОСЛЕДОВАТЕЛЬНОЙ
ОБРАБОТКИ НЕСКОЛЬКИХ СВЯЗАННЫХ ЛОГИКОЙ БИЗНЕС-ПРОЦЕССА
ТАКИХ КУРСОРОВ
ОДНАКО НА СЛОЙ НИЖЕ ЛЕЖИТ ADO - ЕГО ОБЪЕКТЫ
CONNECTION И RECORDSET , А ДЛЯ НИХ ДОЛЖНЫ НОРМАЛЬНО
РАБОТАТЬ ТРАНЗАКЦИИ ADO.
ТО ЕСТЬ ЕСЛИ ОБРАБОТКА БИЗНЕС-ПРОЦЕССА ВЛОЖЕНА В КОМАНДЫ:

NAME_CON.BEGINTRANS

<БЛОК БИЗНЕС ЛОГИКИ >

NAME_CON.ROLLBACKTRANS

, ТО ПО ИДЕЕ ДОЛЖЕН ПРОИЗОЙТИ ОТКАТ И ВНЕШНЯЯ БАЗА ИЗМЕНИТЬСЯ
НЕ ДОЛЖНА!!!

ОДНАКО ЭКСПЕРИМЕНТЫ ПОКАЗАЛИ СЛЕДУЮЩЕЕ:
ИЗМЕНЕНИЕ СУЩЕСТВУЮЩИХ ЗАПИСЕЙ - ОТКАТЫВАЕТСЯ
ВСТАВКА НОВЫХ ЗАПИСЕЙ - НЕТ!!!

ЗАМЕЧАНИЕ: ДЛЯ ПОЛНОТЫ ЭКСПЕРИМЕНТА АНАЛОГ БИЗНЕС-ЛОГИКИ
БЫЛ ВЫПОЛНЕН С ПРИМЕНЕНИЕМ ТОЛЬКО ADO (БЕЗ КУРСОРА АДАПТЕРА)
В ЭТОМ СЛУЧАЕ С ТЕМ ЖЕ СОЕДИНЕНИЕМ И ТОЙ ЖЕ БАЗОЙ ОТКАТЫВАЕТСЯ
И КОРРЕКТИРОВКА И ВСТАВКА НОВЫХ ЗАПИСЕЙ!!!

ВОПРОС! ГДЕ СОБСТВЕННО ЗАРЫТА ПРИЧИНА ТАКОГО ПОВЕДЕНИЯ.

ДОБРОЕ УТРО ВСЕМ.
ВИДИМО ЭТО ПРЕДПОЛОЖЕНИЕ НЕВЕРНО!
ЕСЛИ БЫ ЭТО БЫЛО ТАК , ТО НЕ ОТКАТЫВАЛИСЬ БЫ И МОДИФИКАЦИИ!
А В МОЕМ СЛУЧАЕ НЕ ОТКАТЫВАЮТСЯ <ТОЛЬКО ВСТАВКИ НОВЫХ ЗАПИСЕЙ!!!>
И ОТКУДА ВЗЯТЬСЯ ДРУГОМУ СОЕДИНЕНИЮ - КУРСОР АДАПТЕР
САМ НЕ ГЕНЕРИРУЕТ НОВЫХ СОЕДИНЕНИЙ!!!

* В ГОЛОВНОЙ ПРОГРАММЕ УСТ. СОЕДИНЕНИЕ(СЕРВЕР INTERBASE 6)
oc=createobject('adodb.connection')
OP_KR=createobject('adodb.recordset')
Oc.provider="LCPI.IBProvider"
OC.Mode=3
oc.isolationlevel=4096
oc.CursorLocation = 3
OP_KR.CURSORTYPE=3
OP_KR.LOCKTYPE=3
VPUT='\\dsr\d:\database\IMBASE.GDB'
oc.open("data source=&VPUT;ctype=win1251;auto_commit=true;auto_commit_level=0x100000;","&vlogin","&vpar")
--------------------------------------------------------------------------
* В LOAD ФОРМЫ , КОТОРАЯ ВИЗУАЛИЗИРУЕТ ВЫБОРКУ

LOCURSOR=CREATEOBJECT('CURSORADAPTER')
select 0
WITH LOCURSOR
.ALIAS = 'proba'
.DATASOURCETYPE = 'ADO'
.DATASOURCE = OP_KR
.SELECTCMD = 'Select * from proba order by f_key'
.DATASOURCE.ACTIVECONNECTION = OC
.KeyFieldList='f_key'
.UpdatableFieldList='f_key,f2,f3'
.UpdateNameList='f_key proba.f_key,f2 proba.f2,f3 proba.f3'
IF .CURSORFILL()
select ('proba')
GO TOP
ELSE
WAIT WINDOW 'ПРОИЗОШЛА ОШИБКА !!!' TIMEOUT 4
quit
ENDIF
ENDWITH
----------------------------------------------------------------------
* НАКОНЕЦ В КНОПКЕ ОБНОВЛЯЮЩЕЙ ДАННЫЕ(СОБСТВЕННО
ПРОПУСКАЮ ФОРМУ ГДЕ ДАННЫЕ vnam и vtu ВВОДЯТСЯ)
oc.begintrans
*** ПОЛУЧАЮ НОВОЕ ЗНАЧЕНИЕ КЛЮЧА ОТ ГЕНЕРАТОРА
COM_KR.COMMANDTEXT="SELECT GEN_ID(PROBA_GEN,1) FROM RDB$DATABASE"
COM_KR.activeconnection=oc
F_GEN=COM_KR.execute()
VNNM=F_GEN.FIELDS('GEN_ID').VALUE
*** СОБСТВЕННО ВСТАВКА НОВОЙ ЗАПИСИ В КУРСОР АДАПТЕР
INSERT INTO PROBA (f_key,F2,F3) VALUES (vnnm,vnam,vtu)
oc.rollbacktrans
*** и выхожу из формы захожу заново - запись есть!!!

Спасибо! -это какая-то зацепка!!!
я так понял,что режим авто подтверждения транзакций
надо попробовать отключить.
Я правда сам раньше про это подумал,но почему-то
при отключении этого режима дал сбой кусок кода создания
курсора адаптера и я до конца проверку не закончил.

ДОБРОЕ УТРО!
ОТМЕНИЛ AUTU_COMMIT - ВОССТАНОВИЛ РАБОТУ ПРОГРАММЫ
ВВЕДЯ РЯД РУЧНЫХ ТРАНЗАКЦИЙ И ПОНЯЛ ЧТО К ЧЕМУ!!
ОКАЗЫВАЕТСЯ INSERT INTO В АДО И В КУРСОРЕ АДАПТЕРЕ
ИМЕЮТ РАЗНЫЙ МЕХАНИЗМ РАБОТЫ:
В АДО ДАВ INDSERT INTO МЫ СРАЗУ ИНИЦИАЛИЗИРУЕМ
ОБНОВЛЕНИЕ СЕРВЕРА (И UPDATE ДАВАТЬ НЕ НАДО!!!)
В КУРСОРЕ АДАПТЕРЕ ЕСЛИ ПОСЛЕ INSERT INTO НЕ ДАТЬ
TABLEUPDATE() ИЗМЕНЕНИЯ ВСТАВКИ В СЕРВЕР ОТКЛАДЫВАЮТСЯ
ДО ЗАКРЫТИЯ КУРСОРА АДАПТЕРА, ТО ЕСТЬ ВЫНОСЯТСЯ ЗА МОЮ
РУЧНУЮ ТРАНЗАКЦИЮ!!! (А ПРИ ЗАКРЫТИИ AUTO COMMIT !!!)

ТАК ЧТО ВОССТАНОВИЛ AUTO COMMIT ,
ПЕРЕД INSERT INTO ПОСТАВИЛ
SELECT ('PROBA')
ПОСЛЕ INSERT INTO
=TABLEUPDATE()

И МОЯ РУЧНАЯ ТРАНЗАКЦИЯ ЗАРАБОТАЛА ПРАВИЛЬНО!!!

СПАСИБО ЗА СОДЕЙСТВИЕ - ИНОГДА ДАЖЕ НЕПРАВИЛЬНЫЕ
ДЕЙСТВИЯ ДАЮТ РЕЗУЛЬТАТ!