|
|
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Никак не могу найти здесь топик по этому вопросу, но помню что недавно это обсуждалось. Вобщем один юзер редактирует строку с скюля, в этот момент другой юзер хочет тоже отредоктировать. Как здесь распределять доступ редактирования по очереди? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2006, 00:19 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Какая СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2006, 01:17 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
2 Alex_Ustinov MSSQL2000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2006, 19:06 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
НедоходящийНикак не могу найти здесь топик по этому вопросу, но помню что недавно это обсуждалось. Вобщем один юзер редактирует строку с скюля, в этот момент другой юзер хочет тоже отредоктировать. Как здесь распределять доступ редактирования по очереди? Зависит от буферизации (в самом VFP). Если 1 - то кто первый начал, другой не сможет... Если Выше, например 5 - то каждый свободно редактирует запись, потом записывает... Можно обработать при записи ошибку, если кто-то запись изменил пока ее Вы меняли... Поищите ответы Владимира Максимова на аналогичные вопросы, плюс его статья на тему буферизации... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2006, 21:23 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Hi Недоходящий! > один юзер редактирует строку с скюля, в этот момент другой юзер хочет тоже > отредоктировать. Замечательно - пускай реактирует, пускай даже пользователей будет не 2 а 200 - это совершенно ничего не меняет. > Как здесь распределять доступ редактирования по очереди? Никак. Блокировать записи "пока первый не завершит править запись" это порочная практика - гораздо лучше разрешать возникающие конфликты в момент сохранения - для этого в фоксе есть все средства - читай хелп, смотри примеры в FFC... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 01:57 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Как вы сами отнеслись бы к следующей ситуации: вы редактируете текст (например один из модулей вашей программы) и при попытке его сохранения система выдаёт вам сообщение, что вы ранее этот самый модуль был изменён другим пользователем и изменения, внесённые вами, будут проигнорированы (естественно по системным соображениям) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 12:45 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
2 Igor Korolyov А что такое FFC? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 13:15 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
автор FoxPro Foundation Classes ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 13:42 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgosКак вы сами отнеслись бы к следующей ситуации: вы редактируете текст (например один из модулей вашей программы) и при попытке его сохранения система выдаёт вам сообщение, что вы ранее этот самый модуль был изменён другим пользователем и изменения, внесённые вами, будут проигнорированы (естественно по системным соображениям) Написание ПО - это одно, а ведение учета на предприятии - совершенно другое. Вы можете представить не теоретическую, а практическую ситуацию, когда два менеджера одновременно вводят заказ от одного и того же клиента? Где в это время находится клиент? Или могут ли два разных человека редактировать данные одной накладной? У кого она в это время в руках? Даже если оба работают по копии документа - в БД в результате все равно окажутся одни и те же данные. Потому что накладная - одна, и оба пользователя вносят в базу одно и то же. Случаи, когда требуется разделение доступа на программном уровне, в жизни случаются крайне редко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 13:59 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgosКак вы сами отнеслись бы к следующей ситуации: вы редактируете текст (например один из модулей вашей программы) и при попытке его сохранения система выдаёт вам сообщение, что вы ранее этот самый модуль был изменён другим пользователем и изменения, внесённые вами, будут проигнорированы (естественно по системным соображениям) Написание ПО - это одно, а ведение учета на предприятии - совершенно другое. Вы можете представить не теоретическую, а практическую ситуацию, когда два менеджера одновременно вводят заказ от одного и того же клиента? Где в это время находится клиент? Или могут ли два разных человека редактировать данные одной накладной? У кого она в это время в руках? Даже если оба работают по копии документа - в БД в результате все равно окажутся одни и те же данные. Потому что накладная - одна, и оба пользователя вносят в базу одно и то же. Случаи, когда требуется разделение доступа на программном уровне, в жизни случаются крайне редко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 14:03 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
karly™ Вы можете представить не теоретическую, а практическую ситуацию, когда два менеджера одновременно вводят заказ от одного и того же клиента? Где в это время находится клиент? Или могут ли два разных человека редактировать данные одной накладной? У кого она в это время в руках? Даже если оба работают по копии документа - в БД в результате все равно окажутся одни и те же данные. Потому что накладная - одна, и оба пользователя вносят в базу одно и то же. Случаи, когда требуется разделение доступа на программном уровне, в жизни случаются крайне редко. Двумя руками за то, что вы написали. Сама возможность редактирования одной записи в интрерактивном режиме в один и тот же момент разными пользователями в реальной учетной системе просто не должна возникать. Если она возникает, то что-то, как говорит классик "надо в консерватории подправить". Имею большой опыт внедрения учетных систем на разных по масштабу предприятиях и проблеммы одновременного интерактивного редактирования одних данных никогда не возникала. С уважением, Алексей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 14:12 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Как насчёт редактирования данных одного и того же клиента двумя операторами? Или данных поставщика? Или продукции? Думаю, что таких ситуаций достаточно много. Насчёт накладных тоже не всё так просто: представьте себе, что один из операторов модифицирует накладную, а другой решил эту же накладную просмотреть. В принципе проблемм никаких. Но вот беда - юзеры, с которыми я сталкивался для простого просмотра лезут в модификацию, а при выходе ещё и актуализируют данные. То есть "защиту от юзера" надо на чём то строить и думаю что лучший способ это блокировка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 14:32 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgosКак насчёт редактирования данных одного и того же клиента двумя операторами? Или данных поставщика? Или продукции? Думаю, что таких ситуаций достаточно много. Разные операторы в одно и то же поле вносят разные данные? Т.е. если меняют, например, адрес, то каждый оператор внесет разные адреса в карточку клиента? Вероятно, все-таки одинаковую. Ну, возможно, будут синтаскические ошибки. Нормальная логика системы, ничего не переспрашивая, записать те данные, которые были введены позднее. Т.е. просто затереть модификацию одного из пользователей. Если разные операторы меняют разную информацию (один адрес, другой контактный телефон), то зачем же блокировать запись. Пусть меняют. Нет причны для конфликта. Опять никаких проблем. burgosНасчёт накладных тоже не всё так просто: представьте себе, что один из операторов модифицирует накладную, а другой решил эту же накладную просмотреть. В принципе проблемм никаких. Но вот беда - юзеры, с которыми я сталкивался для простого просмотра лезут в модификацию, а при выходе ещё и актуализируют данные. То есть "защиту от юзера" надо на чём то строить и думаю что лучший способ это блокировка. А это уже исключительно твои проблемы как программиста! Ты, лично ты, не смог разделить на программном уровне процесс просмотра и процесс внесения изменений. Не смог корректно организовать пользовательский интерфейс. Блокировки тут вообще ни с какого боку. При буферизации процесс внесения изменений и процесс собственно сохранения внесенных изменений - это два разных процесса. Факт внесения изменений и факт необходимости сохранения этих изменений анализируется в момент выхода из формы. Далее, в зависимости от принятой идеологии приложения может быть запущен процесс сохранения сделанных изменений если это необходимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 14:56 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
ВладимирМА это уже исключительно твои проблемы как программиста! Ты, лично ты, не смог разделить на программном уровне процесс просмотра и процесс внесения изменений. Не смог корректно организовать пользовательский интерфейс. Блокировки тут вообще ни с какого боку. Процесс просмотра и модификации разделён, так что с интерфейсом всё в порядке. Проблема не в интерфейсе, а в опции, которую выбирает пользователь. Думаю, что программа должна иметь защиту в аналогичных ситуациях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 15:21 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgos ВладимирМА это уже исключительно твои проблемы как программиста! Ты, лично ты, не смог разделить на программном уровне процесс просмотра и процесс внесения изменений. Не смог корректно организовать пользовательский интерфейс. Блокировки тут вообще ни с какого боку. Процесс просмотра и модификации разделён, так что с интерфейсом всё в порядке. Проблема не в интерфейсе, а в опции, которую выбирает пользователь. Думаю, что программа должна иметь защиту в аналогичных ситуациях. Нет! Это именно недоработка интерфейса! Ну, не должно быть каких-то там "опций" при выборе документа. Потом, когда документ уже открыт ты можешь что-то там регулировать. Например, по умолчанию, документ открывается в режиме "только чтение", а для модификации надо нажать дополнительную кнопку. Да и то, это еще надо подумать, стоит ли это делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 15:33 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
ВладимирМ burgos ВладимирМА это уже исключительно твои проблемы как программиста! Ты, лично ты, не смог разделить на программном уровне процесс просмотра и процесс внесения изменений. Не смог корректно организовать пользовательский интерфейс. Блокировки тут вообще ни с какого боку. Процесс просмотра и модификации разделён, так что с интерфейсом всё в порядке. Проблема не в интерфейсе, а в опции, которую выбирает пользователь. Думаю, что программа должна иметь защиту в аналогичных ситуациях. Нет! Это именно недоработка интерфейса! Ну, не должно быть каких-то там "опций" при выборе документа. Потом, когда документ уже открыт ты можешь что-то там регулировать. Например, по умолчанию, документ открывается в режиме "только чтение", а для модификации надо нажать дополнительную кнопку. Да и то, это еще надо подумать, стоит ли это делать. Хорошие у Вас клиенты - просто идеальные. Мои к сожалению больше смотрят на удобство своей работы и не на то, чтобы облегчить мне программирование. В заключение всё таки отвечу инициатору данной дискуссии (а то мы про него как-то забыли ). Начну с того что средствами самого SQL2000 я добился "нормальной" блокировки только одной записи. Говорю "нормальной" так как при попытке заблокировать несколько записей результат, как правило, зависел от числа записей и ни коим образом не совпадал с ожидаемым. Процесс, который я применяю в настоящее время, основан на создании процесса с уникальным именем. При разблокировке этот процесс удаляется. Эту идею я заимствовал в каком-то форуме (может даже и в этом) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 18:44 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
ВладимирМ Нет! Это именно недоработка интерфейса! Ну, не должно быть каких-то там "опций" при выборе документа. Потом, когда документ уже открыт ты можешь что-то там регулировать. Например, по умолчанию, документ открывается в режиме "только чтение", а для модификации надо нажать дополнительную кнопку. Да и то, это еще надо подумать, стоит ли это делать Полностью поддерживаю. Блокировку можно использовать, если очень хочется поиздеваться над пользователями) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:04 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
Лично мне, ближе ситуация - это когда пользователь, открывший например, накладную заблокирует ее как для просмотра, так и для редактирования - до тех пор, пока с ней сам работает. В реальной жизни, возможность одновременного доступа, даже, если другие имеют возможность только просмотра, кроме одного, ни к чему хорошему не приводит, кроме как к дополнительной трате нервов и времени как пользователей так программиста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:19 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
авторЛично мне, ближе ситуация - это когда пользователь, открывший например, накладную заблокирует ее как для просмотра, так и для редактирования - до тех пор, пока с ней сам работает. В реальной жизни, возможность одновременного доступа, даже, если другие имеют возможность только просмотра, кроме одного, ни к чему хорошему не приводит, кроме как к дополнительной трате нервов и времени как пользователей так программиста. В реальной жизни другой пользователь, которому тоже надо открыть документ в соответствии со своими правами, начинает обрывать телефон программиста. И, после того как первый пользователь отпустит заблокированную запись, сделает необходимые ему изменения ни смотря ни на что. Поэтому на практике используется вариант "кто последний, тот и отвечает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:43 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
космонахт В реальной жизни другой пользователь, которому тоже надо открыть документ в соответствии со своими правами, начинает обрывать телефон программиста. Это происходит тогда, когда другой пользователь не понимает – почему ему не доступна данная накладная. А вот когда ему на экране появится сообщение – типа «С данной накладной работает -Петя», тогда он или звонит к Пете или идет к нему, но не к программисту космонахт Поэтому на практике используется вариант "кто последний, тот и отвечает". Правильно, вот как раз при работе одного единственного пользователя с данной накладной в данное время, четко видно - кто последний изменял ВСЮ накладную, а не часть ее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 20:15 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
космонахт авторЛично мне, ближе ситуация - это когда пользователь, открывший например, накладную заблокирует ее как для просмотра, так и для редактирования - до тех пор, пока с ней сам работает. В реальной жизни, возможность одновременного доступа, даже, если другие имеют возможность только просмотра, кроме одного, ни к чему хорошему не приводит, кроме как к дополнительной трате нервов и времени как пользователей так программиста. В реальной жизни другой пользователь, которому тоже надо открыть документ в соответствии со своими правами, начинает обрывать телефон программиста. И, после того как первый пользователь отпустит заблокированную запись, сделает необходимые ему изменения ни смотря ни на что. Поэтому на практике используется вариант "кто последний, тот и отвечает". В общем подход интересный: пусть разбираются пользователи, лишь бы мне не звонили... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 20:46 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgos В общем подход интересный: пусть разбираются пользователи, лишь бы мне не звонили... Ну, если программисту больше нечего делать, то пусть, конечно, “разруливает “ все подряд - и свое и чужое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 21:15 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
2 космонахт Почему блокировка - поиздеваться над пользователями?? Я с этим не соглдасен. Я думаю что блокировка нужна чтоб не допустить конфликтов в тех случаях, когда это необходимо. Т.е. если кто-то изменяет данную строку и другой через 10 сек решил тоже внести туда свою лепту, то надо зделать так чтоб первый закончил редоктирования, а потом второй. >>В реальной жизни другой пользователь, которому тоже надо открыть документ в соответствии со своими правами, начинает обрывать телефон программиста. >>И, после того как первый пользователь отпустит заблокированную запись, сделает необходимые ему изменения ни смотря ни на что. >>Поэтому на практике используется вариант "кто последний, тот и отвечает". Это только в некоторых случаях, да и то не все пользователи будут так довольны. Первый кто закончил вносить изменения потом увидит, что, то что он вносил вдруг совсем ен то, то телефон будет плавиться от непоняток и матов от юзера:типа "- Какого ХХХХХ пропали мои данные!!!???? Только что внес и они соми собой заменились!" А когда есть очередь редоктирования с Историей редоктирования то тогда я думаю юзер уже будет звонить не мне а тому кто после него изменил. 2 -) С тобой согласен. 2 burgos Вот поэтому и надо делать так чтоб не звонили и всем юзерам отображалось инфа в проге на вопрос :"- А почему ...??" 2 ВладимирМ Затереть инфу без запроса - это я поддерживаю, но надо чтоб затиралась по очереди и не все вместе. Поповоду кнопки это интересно. Владимир, А как вы организовываете базы данных?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 11:36 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
авторКакого ХХХХХ пропали мои данные!!!???? Только что внес и они соми собой заменились!" А когда есть очередь редоктирования с Историей редоктирования то тогда я думаю юзер уже будет звонить не мне а тому кто после него изменил. Если оператор имеет доступ к документу, то он отвечает за весь документ, а не отдельные его атрибуты. И, если он сохранил документ, то с него и спрос. Неужели где-то на практике встечается ситуация, когда, например, в платежке одна девушка-оператор набивает только получателя, другая плательщика, третья дату, еще одна номер, следующая сумму и т.д....? При такой ситуации что-то в менеджменте надо править... ничто не слишком! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 12:14 |
|
||
|
Одновременное редактирование строки на SQL
|
|||
|---|---|---|---|
|
#18+
burgosКак вы сами отнеслись бы к следующей ситуации: вы редактируете текст ( например один из модулей вашей программы ) и при попытке его сохранения система выдаёт вам сообщение, что вы ранее этот самый модуль был изменён другим пользователем и изменения, внесённые вами, будут проигнорированы (естественно по системным соображениям) про одновременное написание одного и того же модуля одной итой же программы - это Вы сильно сказали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 12:20 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33773387&tid=1591437]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
389ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 217ms |
| total: | 707ms |

| 0 / 0 |
