Здравствуйте.

VFP 6.0 SP5.

Как правило формы, которые используются в проекте, работают в private data session и открывают необходимые для работы view в собственном data environment. Модификация данных производится с помощью
begin transaction, tableupdate, tablerevert, end transaction, rollback. Некоторые формы modelless и, соответственно, возможен запуск нескольких экземпляров формы одновременно.

Если в качестве backend выступает сам Visual Foxpro, то видимость транзакции ограничивается data session и rollback в одной из них не влияет на выполнение транзакций в других datasession.


Что будет происходить, если в качестве backend выступает SQL Server и используются remote view с shared connection?
Все remote view используют один и тот же Connection Handle и, стало быть, SQLRollBack в одной из форм (data session) будет влиять на выполнение транзакций в других формах (data session)? так ли это? Как можно форсировать выделение отдельного Connection для private data session?

Спасибо

А мне чего-то казалось, что dataSession к транзакциям имеет непосредственное отношение. Я ведь могу, К ПРИМЕРУ, запустить 20 экземпляров формы, каждую в private data session и к в каждой начать транзакцию. В default data session этого не получится из-за ограничения по максимальному уровню вложенности транзакций. Следовательно, я предполагаю, что транзакции в VFP живут в мире ограниченным data session. И транзакция из одной data session не знает о транзакциях в других.

Я ожидал, что при использовании remote view, VFP создаст отдельный "мир" для работы с транзакциями на remote backend - для каждой datasession создаст отдельный connect и откроет все remote view из конкретного dataenvironment в этом коннекте, если используестя Shared Connection.

Спасибо.

Я понимаю, что необходимо пытаться минимизировать время между begin transaction и end transaction/rollback. Вопрос не в этом.

Я пытаюсь понять отношения между data session и обработкой транзакций. ПРИМЕР, в котором begin transaction выполняется на Load Event, использовал для выяснения этой связи и к реальной обработке транзакций отношения не имеет. ПРИМЕР показал, что транзакции "живут" в data Session.

Вопрос в другом: является ли private data session аналогом еще одного пользователя с точки зрения обработки транзакций. Когда VFP работает с native данными, то да - транзакция дальше data session не видит и тем более не видит другого пользователя.

Что происходит, когда используются remote view с shared connection?
Если работают различные пользователи, то проблемы нет - они используют различные соединения с точки зрения удалённой СУБД.
А вот если один и тот же пользователь открыл второй экземпляр формы(или другую форму), то с точки зрения backend - это одно и то же соединение, а с точки зрения VFP две различные формы, две различные data session. И если в одной из data session(в одной из форм) выполнить RollBack на удаленных данных, то он распространиться на весь Connect и, следовательно, на несколько data sessions и даже на те, в которых все модификации прошли удачно и оставалось выполнить лишь Commit.
В результате, все TableUpdate пройдут успешно, Commit пройдёт успешно, а модификации данных не произойдет - RollBack из другой data session, но на том же Connection, выполнился на мгновения раньше, чем Commit.

Получается, что private data session не совсем private для remote view?
Можно ли заставить VFP создавать отдельный Connection для каждой data session и потом форсировать открытие view из dataEnvironment через этот Connection?

Спасибо

2 1024
В конечном итоге хочу получить отдельный ConnectionHanlde для каждой data session и заставить VFP открывать remote view из этого data session используя этот ConnectionHandle.

Спвсибо

2 ВладимирМ
Спасибо. Я поиграюсь/поэкспериментирую может чего выкрутить получиться...

Относительно модификации Connection в RemoteView/создания временной локальной базы тоже подумаю. Хотя как и Вам мне кажется, что использование такого подхода, не совсем удачное решение.

Есть ли какой-либо способ влезть в SQLConnect?

Спасибо.

2 Crip
Прошу прощения,но я Вас не совсем понял.

Когда Вы употребляете выражение "Оптимистическая блокировка", то имеется ввиду "row/table buffering" из VFP или некая другая блокировка, возникающая на удалённой СУБД?

Что Вы имеете ввиду утверждая, что транзакции возможны только при использовании SQL Pass Through? Установите, К ПРИМЕРУ, в VFP ручной режим управления транзакциями и откройте RemoteView - у Вас открытая транзакция.При желании её можно тут же закрыть SQLRollback(CursorGetProp("connectionHanlde")).
Выполните CursorSetProp("buffering",5)- table buffering. Выполните Browse. Поизменяйте чего либо в данных(remoteview должен быть updatable).
Выполните TableUpdate(1,.f.) - на удалённой СУБД прошли insert/update/delete(в зависимости от действий в Browse.), которые повлекли за собой при необходимости неявное начало транзакции. Осталось транзакцию закрыть.
Выполните SQLCommit(CursorGetProp("connectionHanlde")).
С моей точки зрения, несмотря на использование SQLCommit и SQLRollback, которые относятся к SQL Pass Through функциям, в этом примере используется технология RemoteView - в Remote View описаны поля, таблицы, ключи, тип апдейта.

Спасибо

2 Crip

1)Что вы хотите сделать? Откатывать TableUpdate?
Да нет, хотел сказать, что транзакции возможны не только при использовании технологии SQL Pass Through, но и при использовании технологии Remote View.

Относительно блокировок на удалённой БД: мне видится, что блокировки совершенно одинаковые, при прочих равных условиях, будь то SELECT выполненный через SQL Pass Through или SELECT выполненный в результате открытия/requery remote view. Или БД знает, что это SELECT выполняется через SQL Pass Through и как-то по особому его обрабатывает? Сомневаюсь

У меня по ходу возник практический вопрос: как поле типа datetime на удалённой БД замэпить в VFP поле типа date с использованием технологии SQL Pass Through? Как управлять типами полей в результируещем курсоре при использовании SQL Pass Through?

Спасибо