|
|
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
такая вот ерунда: один клиент открыл табличку для редактирования, в буферизации оптимистик (VFP6) другой клиент открывает view на основе этой таблички, для внесения изменений, тоже буфер оптим. (VFP9), если в отладке из под фокса, то ничего, нормально отрабатывает, если скомпилиную пускает, прога говорит нет доступа к табл. т.е. прога дает ошибку и вылетает... как быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 05:42 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Po umolchaniu v Foxe stoit set exclusive on Postavte SET EXCLUSIVE OFF i vse budet horosho. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 06:14 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
kdanyloPo umolchaniu v Foxe stoit set exclusive on Postavte SET EXCLUSIVE OFF i vse budet horosho. все и перавда стало horosho!!! теперь друга тема, если они паралельно влезли в одно поле и внесли изменения, то ситуация повторяется... наверно есть какие-то ловушки, чтобы отловить и подождать пока первый закончит, а второму показать что первый сделал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 07:32 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
фокстеперь друга тема, если они паралельно влезли в одно поле и внесли изменения, то ситуация повторяется... наверно есть какие-то ловушки, чтобы отловить и подождать пока первый закончит, а второму показать что первый сделал? Смотри функции: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 08:06 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
наверно есть какие-то ловушки, чтобы отловить и подождать пока первый закончит, а второму показать что первый сделал Tochno. Lovushki nazyvayutsia blokirovkami. Te problemy kotorye vy vidite est' konfliktami obnovleniya. Tema dostatochno slojnaya. Est' horoshiy primer v 'Solutions', kotoroe postavlyaetsia vmeste s Foxom. Primer nazyvaetsia: "Handle Data Conflicts" i nahoditsia v razdele 'Foundation Classes'. Mojet bit' zapushcheno iz komandnogo okna: DO HOME(2) + ("solutions\solution.app") Esli u vashego view ustanovka 'SQL WHERE clause includes' budet 'Key Fields Only' conflict budet voznikat' tol'ko esli vy meniaete znachenie klucha. A takogo po-moemu nedoljno bit' nikogda (IMHO). Nu i help - luchshiy resource. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 08:24 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
kdanylo наверно есть какие-то ловушки, чтобы отловить и подождать пока первый закончит, а второму показать что первый сделал Tochno. Lovushki nazyvayutsia blokirovkami. Te problemy kotorye vy vidite est' konfliktami obnovleniya. Tema dostatochno slojnaya. Est' horoshiy primer v 'Solutions', kotoroe postavlyaetsia vmeste s Foxom. Primer nazyvaetsia: "Handle Data Conflicts" i nahoditsia v razdele 'Foundation Classes'. Mojet bit' zapushcheno iz komandnogo okna: DO HOME(2) + ("solutions\solution.app") Esli u vashego view ustanovka 'SQL WHERE clause includes' budet 'Key Fields Only' conflict budet voznikat' tol'ko esli vy meniaete znachenie klucha. A takogo po-moemu nedoljno bit' nikogda (IMHO). Nu i help - luchshiy resource. пример на картинке хороший, я вспомнил что так уже делал, но сдесь другая проблемка, дело в том, что пользователь не узнает что поле уже было изменено, а просто затрет его... но для меня в данном случае это не критично. а что вы пишите латиницей? издалека? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 09:09 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Da, iz Kanady. "Handle Data Conflicts" - primer kak uvedomliat' pol'zovatelia o podobnyh konfliktah i predostvit' vozmojnost' perezapisat' ili otmenit' ih esly kto-to drugoy uje uspel zapisat' svoi izmenenia. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 09:27 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
kdanyloDa, iz Kanady. "Handle Data Conflicts" - primer kak uvedomliat' pol'zovatelia o podobnyh konfliktah i predostvit' vozmojnost' perezapisat' ili otmenit' ih esly kto-to drugoy uje uspel zapisat' svoi izmenenia. посмотрел, у меня в view именно так и стоит эта настройка, я думаю конфликт возникает изза того, что оптимистик блокирует запись , получается одну запись пишут два клиента... как там в канаде, фокс котируется? или вы там по другому профилю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 09:42 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
как там в канаде, фокс котируется? Fox normal'no. Tol'ko vakansiy na rabotu pochti .NET посмотрел, у меня в view именно так и стоит эта настройка, я думаю конфликт возникает изза того, что оптимистик блокирует запись , получается одну запись пишут два клиента... Optimistic blokiruet zapis' tol'ko vo vremia vipolnenia TableUpdate(). Mojet eto ne view confliktuet ili vy meniaete znachenie kliucha view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 09:51 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
kdanylo как там в канаде, фокс котируется? Fox normal'no. Tol'ko vakansiy na rabotu pochti .NET посмотрел, у меня в view именно так и стоит эта настройка, я думаю конфликт возникает изза того, что оптимистик блокирует запись , получается одну запись пишут два клиента... Optimistic blokiruet zapis' tol'ko vo vremia vipolnenia TableUpdate(). Mojet eto ne view confliktuet ili vy meniaete znachenie kliucha view. платят хоть нормально? нет значение ключа не меняю, как-то не каждый раз конфликтует, буду ловить в какой момент и отчего.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 10:04 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
платят хоть нормально? Komu kak ... Samiy bol'shoy plus - yesli rabochiy den' 8 chasov - on deystvitel'no 8 chasov. Posle 5 -ti na rabote nikogo net. Hotia v drugih mestah mojet bit' po-drugomu. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 10:44 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
kdanylo платят хоть нормально? Komu kak ... Samiy bol'shoy plus - yesli rabochiy den' 8 chasov - on deystvitel'no 8 chasov. Posle 5 -ti na rabote nikogo net. Hotia v drugih mestah mojet bit' po-drugomu. кроме фокса что котируется? Оракл? МССКЛ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 11:05 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Smotrite sami: www.monster.ca http://www.jobbank.gc.ca/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 11:19 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Hi kdanylo! > Esli u vashego view ustanovka 'SQL WHERE clause includes' budet 'Key > Fields Only' conflict budet voznikat' tol'ko esli vy meniaete znachenie > klucha. A takogo po-moemu nedoljno bit' nikogda (IMHO). Однако может быть ситуация удаления - т.е. пока мы правили кто-то там извне запись удалил - так что и без правки PK может возникнуть конфликт. При этом он весьма сложно разрешается - поскольку неясно что лучше сделать - восстановить старую запись, или ввести новую... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2005, 04:05 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Hi kdanylo! > Esli u vashego view ustanovka 'SQL WHERE clause includes' budet 'Key > Fields Only' conflict budet voznikat' tol'ko esli vy meniaete znachenie > klucha. A takogo po-moemu nedoljno bit' nikogda (IMHO). Однако может быть ситуация удаления - т.е. пока мы правили кто-то там извне запись удалил - так что и без правки PK может возникнуть конфликт. При этом он весьма сложно разрешается - поскольку неясно что лучше сделать - восстановить старую запись, или ввести новую... Posted via ActualForum NNTP Server 1.3 ествно - ввести нову, вы по логике рассудите: тот кто удалил - ему не надо тот кто правил - ему надо новую так что лучше? старую востановить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2005, 12:20 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Hi FoXXX! > ествно - ввести нову, вы по логике рассудите: > тот кто удалил - ему не надо > тот кто правил - ему надо новую > так что лучше? старую востановить? Если бы всё было так просто... Удалили клиента, каскадно удалили скажем его заказы - в это-же время некто другой "правил" ФИО данного клиента - надо ли восстанавливать эту запись? Надо ли восстанавливать удалённые заказы (их то наверняка видел тот кто правил ФИО - то то он удивится - исправил ФИО, и тут вдруг исчезли все заказы). А если восстанавливать не надо, а завести новую запись, то что потом произойдёт когда "удаливший" клиента пользователь побежит к программисту и будет слёзно его просить "вернуть как было" - а в справочнике клиентов то уже есть этот клиент - и "просто RECALL пары записей" уже не поможет... Бизнес логика - это та самая вещь, где есть бизнес, но абсолютно нету логики :) Так что "заочно" решить такой вопрос нельзя - в каждом конкретном случае будет необходимо своё частное решение проблемы. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 00:37 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Hi FoXXX! > ествно - ввести нову, вы по логике рассудите: > тот кто удалил - ему не надо > тот кто правил - ему надо новую > так что лучше? старую востановить? Если бы всё было так просто... Удалили клиента, каскадно удалили скажем его заказы - в это-же время некто другой "правил" ФИО данного клиента - надо ли восстанавливать эту запись? Надо ли восстанавливать удалённые заказы (их то наверняка видел тот кто правил ФИО - то то он удивится - исправил ФИО, и тут вдруг исчезли все заказы). А если восстанавливать не надо, а завести новую запись, то что потом произойдёт когда "удаливший" клиента пользователь побежит к программисту и будет слёзно его просить "вернуть как было" - а в справочнике клиентов то уже есть этот клиент - и "просто RECALL пары записей" уже не поможет... Е мое, а ведь точно, и чтоже делать??????? вообще не понятно как разруливать эту ситуацию, особенно при работе с вьюшками %-)) Игорь, может поможите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 03:24 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Hi FoXXX! > ествно - ввести нову, вы по логике рассудите: > тот кто удалил - ему не надо > тот кто правил - ему надо новую > так что лучше? старую востановить? Если бы всё было так просто... Удалили клиента, каскадно удалили скажем его заказы - в это-же время некто другой "правил" ФИО данного клиента - надо ли восстанавливать эту запись? Надо ли восстанавливать удалённые заказы (их то наверняка видел тот кто правил ФИО - то то он удивится - исправил ФИО, и тут вдруг исчезли все заказы). А если восстанавливать не надо, а завести новую запись, то что потом произойдёт когда "удаливший" клиента пользователь побежит к программисту и будет слёзно его просить "вернуть как было" - а в справочнике клиентов то уже есть этот клиент - и "просто RECALL пары записей" уже не поможет... Бизнес логика - это та самая вещь, где есть бизнес, но абсолютно нету логики :) Так что "заочно" решить такой вопрос нельзя - в каждом конкретном случае будет необходимо своё частное решение проблемы. Posted via ActualForum NNTP Server 1.3 может я не так выразился, но я думаю необходимо востановить старую с новыми изменениями которые внес правивший, т.е. записать новую информацию но на старую запись, т.е. изменения внести! внести на удаленную запись и все востановить! если после они решат удалить все-таки клиента - удалят, вечно повторяться данная ситуация не может (один удаляет - другой правит), кроме того я веду протокол через тригеры, кто что делал с данной записью, и развести пользователей всегда можно на основании этого протокола. каскадное удаление тоже отслеживается. оно не должно срабатывать если запись редактируется в данный момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 04:49 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Hi FoXXX! Хорошо, зайдём с другой стороны - юзер1 удалил клиента и все его заказы (неважно руками или каскадный триггер это сделал). Юзер2 правил некоторый конкретный заказ - например поменял там "шило" на "мыло" и пытается сохранить - как ты думаешь, удастся ли тебе восстановить удалённыю запись? Я полагаю что при правильной настройке триггеров (в частности Restrict на Insert) не удастся и это правильно. Если же каким-то чудом всё-же этот трюк будет сделан, то мы получим классическую "сироту" в таблице заказов. Заметь, мы пока рассматриваем лишь самые примитивные случаи! 2 Иван - читай самый последний абзац. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 19:23 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Hi FoXXX! Хорошо, зайдём с другой стороны - юзер1 удалил клиента и все его заказы (неважно руками или каскадный триггер это сделал). Юзер2 правил некоторый конкретный заказ - например поменял там "шило" на "мыло" и пытается сохранить - как ты думаешь, удастся ли тебе восстановить удалённыю запись? Я полагаю что при правильной настройке триггеров (в частности Restrict на Insert) не удастся и это правильно. Если же каким-то чудом всё-же этот трюк будет сделан, то мы получим классическую "сироту" в таблице заказов. Заметь, мы пока рассматриваем лишь самые примитивные случаи! 2 Иван - читай самый последний абзац. Posted via ActualForum NNTP Server 1.3 да не может удалиться запись - если кто-то корректирует ее, или вложенную(зависимую запись)!!! удаление будет остановленно - юзеру система скажет: пользователь пупкин захватил запись и правит ее - вы не можете пока ее удалить!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 04:39 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
~Иван~ Е мое, а ведь точно, и чтоже делать??????? вообще не понятно как разруливать эту ситуацию, особенно при работе с вьюшками %-)) Игорь, может поможите А я например, чтобы не заморачиваться кнопку удаления клиентов просто делаю невидимой... то есть не даю простому юзеру удалять что-то из справочников. Конечно подход мой неверен, зато геморроя меньше.. а если надо им удалить кого-то то "Технологические работы" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 09:34 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
FoXXX да не может удалиться запись - если кто-то корректирует ее, или вложенную(зависимую запись)!!! удаление будет остановленно - юзеру система скажет: пользователь пупкин захватил запись и правит ее - вы не можете пока ее удалить!!! LOCAL VIEW (или Remote View) не блокирует записи, которые он выбрал из таблицы-источника. Это вообще другая таблица. Попытка блокировки происходит только в момент сброса буфера. А блокировка записи при взятии ее на редактирование - это вообще отдельная стратегия программирования. Лично мне она кажется не очень удачной. Впрочем, это уже зависит от конкретной задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 11:26 |
|
||
|
доступ к таблице
|
|||
|---|---|---|---|
|
#18+
разговор ушел в сторону, а проблема осталась, я тут покапался и выяснил, что конфликтуют поля мемо, т.е. если таблица в буфере, а я правлю поле мемо, то запись пишется сразу не дожидаясь tableupd вот тут и возникает конфликт, хотя по логике если таблица в буфере, то и мемо тоже должно быть в буфере, или не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 17:02 |
|
||
|
|
start [/forum/topic.php?fid=41&fpage=284&tid=1592745]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
87ms |
get topic data: |
12ms |
get forum data: |
4ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 451ms |
| 0 / 0 |
