Добрый всем день,

возник вопрос, в форме фрм1 с privat data session (далее DS) создается курсор create cursor ...
потом, в ходе выполнения из этой фрм1 вызывается do form frm2 to myVar, DS - default, из которой в свою очередь вызывается фрм3 , DS - default, где происходит наполнение курсора и возврат в форму фрм1.

А какова будет видимость этого курсора для других пользователей при одновременной работе? Причем все работают через удаленное подключение к рабочему столу, т.е. получается, просто в разных сессиях.



Исправлено 1 раз(а). Последнее : DmitryKn, 01.12.22 16:10

DmitryKn
А какова будет видимость этого курсора для других пользователей при одновременной работе? Причем все работают через удаленное подключение к рабочему столу, т.е. получается, просто в разных сессиях.

Нормальная у него будет видимость. То бишь только кому надо, а не всем подряд. Разные копии программы, запущенные в разных сессиях терминала, полностью изолированы друг от друга. Не надо искать черную кошку в темной комнате, особенно когда ее там нет.

Отлично, спасибо, не был уверен.



Исправлено 1 раз(а). Последнее : DmitryKn, 01.12.22 16:46

Цитата:

А если создается временная таблица temp.dbf на диске, не курсор, DS формы - private, после выполнения процедуры удаляется, чисто теоретически одновременное выполнение процедуры хотя и маловероятно, но не исключено, возможен ли в таком случае конфликт?

Понятие Datasession никак не связано с видимостью таблиц для других пользователей.
Если какая-то таблица может быть открыта другим пользователем (не открыта EXCLUSIVE), то на это не окажет влияние значение Datasession, в которой она открыта у текущего пользователя.

Но и для текущего пользователя Datasession не помешает открытию одной и той же таблице в разных Datasession (если не использовать EXCLUSIVE).

PS
А "временная таблица" для системы и Фокса ничем не отличается от любой другой таблицы - только вы знаете, что она "временная" (это просто ваше определение, никак не влияющее на суть - назовите её хоть "супер-пупер-перепупер таблица").
И если "вдруг" вы не сможете её удалить (кто знает будущее?), то она легко превратится в "безвременную".

С таблицей всплыл вопрос, потому что она физически создается на диске, и в ходе процедуры к ней несколько раз обращаются. Но я их создаю для каждого пользователя в своей папке, так что вопрос сперва задал, потом вспомнил ))

DmitryKn
С таблицей всплыл вопрос, потому что она физически создается на диске, и в ходе процедуры к ней несколько раз обращаются. Но я их создаю для каждого пользователя в своей папке, так что вопрос сперва задал, потом вспомнил

Мне просто показалось, что вы сделали некий "нажим" на том, что эта таблица открыта в private DS.
Так что основная мысль, заложенная в мой ответ - тип DS не имеет никакого отношения к возможности открыть эту таблицу ещё кем-то, в том числе и тем же самым пользователем, то есть к блокировке.

DmitryKn
Добрый всем день,
возник вопрос, в форме фрм1 с privat data session (далее DS) создается курсор create cursor ...
потом, в ходе выполнения из этой фрм1 вызывается do form frm2 to myVar, DS - default, из которой в свою очередь вызывается фрм3 , DS - default, где происходит наполнение курсора и возврат в форму фрм1.

А какова будет видимость этого курсора для других пользователей при одновременной работе? Причем все работают через удаленное подключение к рабочему столу, т.е. получается, просто в разных сессиях.

() Все просто, вроде: раз "создается курсор", то он ведь создается в именованном алиасе (кстати, нужно/можно делать его имя уникальным, например как SYS(2015) - гарантировано уникальное имя), и под этим именем он виден в проге без DS, или в проге с приватными DS - не виден, но с условностями доступа, с блокировками, если блокировки используются...

Доб. "Многопользование" (доступа к таблицам БД) легко проверять просто запустив две копии программы на одном компе - эффект будет тот же самый, что и при работе в "многотерминальной" среде, в "удаленном доступе" к файл-серверу...

of63
и под этим именем он виден в проге без DS

Без DS прог не бывает.

of63
но с условностями доступа, с блокировками, если блокировки используются.

А можно создать не-EXCLUSIVE курсор?

тупым способом - копированием (в видимый файл).. и переоткрытием файла... А это зачем?

akvvohinc

of63
и под этим именем он виден в проге без DS

Без DS прог не бывает.

of63
но с условностями доступа, с блокировками, если блокировки используются.

А можно создать не-EXCLUSIVE курсор?

> Без DS прог не бывает.
<Быват. Про DS не все знают

И, мтк, это тупая ветвь цивилизации фокса

() Все можно создать "копированием" обьекта исследования, да?



Исправлено 2 раз(а). Последнее : of63, 04.12.22 19:30

of63
Быват. Про DS не все знают

Знаешь или не знаешь, но DS есть всегда.

of63
Все можно создать "копированием" обьекта исследования, да?

А зачем нам что-то создавать "копированием для исследования" в теме "Видимость курсора"?

К тому же скопированный курсор превратится в обычный dbf, никак не связанный с курсором.
Можно ли открыть никем не открытый dbf файл? Сомнительно, что этот вопрос кого-то может интересовать.

Да, ты прав, лишние исследования ни к чему
() Сам тоже, перечитываю свой последний пост... восстанавливаю последовательность соображений. Скорее всего, это не интересно никому. Затупил вобщем

У меня почему вопрос этот всплыл:
случается такая ситуация, два пользователя редактируют или создают два разных документа, накладная, и раз в какое-то время , например, раз или пару в несколько месяцев, строки одного юзера исчезают из документа и появляются в документе второго юзера, у которого ситуация строго наоборот, т.е. меняются строками, или у одного из них слетают вообще.
Это происходит, когда идет одновременное сохранение. Я понимаю, что "одновременно" для машины не очень-то и возможно, рабочие папки разные, временные таблицы в разных папках, ну вот создается много курсоров для отбора данных и разных проверок, локал вью в том числе. Но коль скоро они не видны никому, кроме создателя, без особых на то ухищрений, то я и не знаю, что думать.



Исправлено 1 раз(а). Последнее : DmitryKn, 07.12.22 18:17

DmitryKn
два пользователя редактируют или создают два разных документа, накладная, и раз в какое-то время , например, раз или пару в несколько месяцев, строки одного юзера исчезают из документа и появляются в документе второго юзера
Это происходит, когда идет одновременное сохранение.

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

А кто и каким образом определил, что "обмен строками" происходит в ситуации, когда "два пользователя редактируют или создают два разных документа"?



Исправлено 1 раз(а). Последнее : akvvohinc, 07.12.22 22:55

Я бы ещё добавил, похоже в БД нет FK и транзакций.

akvvohinc

DmitryKn
два пользователя редактируют или создают два разных документа, накладная, и раз в какое-то время , например, раз или пару в несколько месяцев, строки одного юзера исчезают из документа и появляются в документе второго юзера
Это происходит, когда идет одновременное сохранение.

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

А кто и каким образом определил, что "обмен строками" происходит в ситуации, когда "два пользователя редактируют или создают два разных документа"?

Это, скорее, юридический вопрос (кто первый создал юридически адекватный док). С точностью до "дня", секунды, времени предоставлоения...


()() все это не важно в реалии... ну.. есть же рейдерские захваты, мочилово, жесты доброй воли, еще что-то

Добрый день,
простите, выпал на несколько дней.

Таблица записей к накладной не имеет уникального ключа, в таблице записей - id таблицы "накладная".
Вообще, структура такая - основной документ Счет, есть примари кей, детали Счета - нет примари, сортировка по id Счет, таблица Накладная, примари кей и id Счета, детали (записи) накладной - нет примари, есть id накладной.
Relations не установлен, отбор по ключам.
для таблиц устанавливается буферизация, после изменений - tablupdate, вот и все транзакции.
По идее пересекаться не могут, но пересекаются, причем очень иногда.

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

Давай DDL таблиц.

PaulWist
Давай DDL таблиц.

С удовольствием предоставлю, но не сильно понимаю что. DDL - Data_Definition_Language , это мне что давать? буферизацию и тэйблапдейты , или структуры таблиц, или что? Не все термины мне известны, извините..(

структуры таблиц + индексы