Доколкото разбрах от написаното човека има проблем не толкова със заключванията, а с рефрешването на данните Не знам на каква СУБД го прави и може от там да идва проблема. Между другото може спокойно да си пази данни и в клиентската част, но тогава отиваме вече на частично или напълно разпределена система и трябва да се грижи за синхронизацията на данните. Ако пише на Access той си поддържа репликация на базата и проблема му е решен. Само трябва да реши през какъв период трябва да синхронизира(отнема не малко време, ако базата е големичка), но пък всеки комп си работи локално и самата програма ще си е по-бързичка.Да не говорим че при пълна репликация на практика едва ли ще загуби данни (освен ако не изгори цялата сграда)
Изобщо решения много. Но при всяко положение първо малко теория преди това

Твърде много залиташ в тази насока сървърът да актуализира данните при клиента. Твоят проблем е съвсем нормален за Client/Server приложения и по принцип в този случай не е желателно сървърът да праща каквото и да било на клиентите, освен *отговори* (представи си например, че това е HTTP-базирано приложение... но дори и да не е...)

Разучи добре нещата свързани с isolation levels, concurency, оптимистични/песимистични заключвания. Добре е да ги знаеш...

Не се отчайвай от мисълта, че на екрана можеш да виждаш данни, които междувременно са били променени, това е съвсем нормално. Имай предвид, че дори и сървърът автоматично да обновява данните на клиентите, това пак няма да те спаси в 100% от случаите ако не рабереш (и приложиш) гореспоменатите "техники". Да не говорим колко би се усложнила логиката и на сървъра и на клиента...

Все пак ще ти дам някои конкретни идеи и насоки за размисъл...

Ако вероятността ти да редактираш тези данни които виждаш е малка, а иначе доста други конкурентни потребители да проявяват интерес към същите данни е голяма, по принцип не е добре да заключваш въпросните записи при прочитането им. Тогава ще трябва просто при опит за модификация да правиш съответните проверки дали нещо не се е случило (и ако е - да направиш каквото прецениш че трябва) ....

И обратното... в други случаи това което ти предлага salle (SELECT ... FOR UPDATE) може да е по-удачния подход...

С други думи... чети за оптимистично / песимистично заключване и т.н...

От всичко написано до тук мисля че Bob ме е разбрал най-точно.

>> "Доколкото разбрах от написаното човека има проблем не толкова със заключванията, а с рефрешването на данните."

Аз потърсих информация в интернет по въпроса за синхронизация на информацията между клиентите и се оказва че най-доброто решение на проблема е чрез сървърна програма, през която минават всички заявки и тя информира клиентите за всички промени.
Но с това за мен проблема на се решава понеже базата данни е PostgreSQL, инсталиран на Linux.
А сега де ...?

И тъй като това е глобален проблем за такива ситеми се чудя защо в сървърите за бази данни няма вградени инструменти, помагащи за решаването на проблема.
Е не съм сигурен дали наистина няма.

Благодаря nasko,
Мился че с твоите насоки и теоретичните основи и препоръки на salle започвам да виждам свтлинка в тунела.

Благодаря на всички!

Access-а не прощава никому. По старото поколение DB програмисти е повредено от clipper -a, лека му пръст(на clippera, не на поколението) и за съжаление следващото върви с други средства по стъпките му.

накратко, connected приложенията стават само за дипломни работи (и в програма за магазин със 2 продажби на ден).
В реалния живот по този начин ще направиш няколко зулума наведнъж:
Ще си изпозаключиш базата както и турчин не я е заключвал(ще си позволя да цитирам соц класиците) ако тръгнеш да селектваш for update - лелята, която влиза в режим редактиране и после отива да пие кафе или вади плетката е класика в жанра.
Ще си задръстиш и мрежата със иди ми/дойди ми рефрешване. Което като цяло трябва да го правиш пак от приложението на някакъв timer event - това в случай че не държиш данни при клиета. Ако данните са при клиента, на практика пак трябва да ги локваш на сървъра(ако ги е взел някой, не трябва останалите да пипат по взетите неща).


Може би най-чисто и безболезнено е да си правиш проверка при запис/изтриване. Една нелоша стратегия е да ползваш timestamp-и. Не знам как точно е при Postgre-тo, но идеята е следната - когато си вземеш данни за редакция ги прибираш със timestamp - някакъв идентификатор за актуална версия на реда в таблицата. Ако при запис не е променена, си ОК. Ако има промяна, или ползваш hardcoded логика, или оставяш user-a да решава какво да прави.

Относно concurrent updates, базата би трябвало да се оправи без много услия от твоя страна.

Споменах ти защо идеята сървърът да обновява клиентите не е препоръчителна, освен ако наистина имаш причини да правиш това... (Не казвам, че не трябва да го правиш. Въпросът е да прецениш дали е оправдано.)

1. Не винаги сървърът има тази физическа възможност (когато протоколът например е HTTP). В такива случаи има подходи като периодични запитвания от страна на клиента (например с JavaScript) но това е съвсем друг въпрос.

2. Дори и сървърът да може да инициира връзка с клиентите и да им праща каквото и когато реши, това има своите сериозни недостатъци, като например, че софтуерът и на клиента, и на сървъра се усложнява значително, както и протоколът за комуникация м/у тях...

3. Това автоматично актуализиране няма да те спаси само по себе си от проблеми с неактуални данни при клиента (освен ако не реализираш специална логика с допълнителни проверки дали си успял да актуализираш данните му и т.н.)...

4. Performance. Помисли си защо...

Всъщност още доста може да се изпише по темата... но мисля, че и гореспоменатото не е слаба причина да се замислиш дали е оправдано всичко това...

Колкото до това дали СУБД-то което ползваш е Postgre или някакво друго, това няма особено значение, тъй като каквато и яка база да ползваш, тя няма как просто ей така да те отърве от всички проблеми свързани с този начин на работа... Впрочем тази функционалност обикновено се реализира чрез някакво приложение което ползва базата, т.е. такова дето стои между базата и клиентите.

А BTW колкото до performance-a, проблемите с него идват не само от слаб хардуер или "слаба" база, но и от неправилна работа с последната... Salle наскоро даде много подходящ пример със SELECT COUNT(*) from Tbl a, Tbl b, Tbl c, Tbl d... А когато говорим за транзакции и isolation levels има още доста какво да се каже по въпроса;)

Има няколко начина по които можеш да реализираш рефрешване на информацията на клиента, които в зависимост от инициативата могат да се класифицират:
1. Event от сървъра. В тригер палиш event (в някои сървъри механизма за ивънта го има вграден, в други може да се изпраща от външна функция)
2. Трислойна структура. Ползва се Application server, който уведомява клиентите за промените.
3. Периодична проверка за настъпили промени инициирана от клиента.

Всеки от горепосочените принципи може да има различни реализации.

Но.....
Както вече те предупредиха, към това трябва да се пристъпва много внимателно и мотивирано.
Защото:
1. Да си представим, че в един момент имаме 300 клиенти (за прегледност нека да са блондинки), които работят с данните (не е чак толкова страшно число)
2. В момента, в който някоя блондинка промени един запис, трябва да се изпълнят 300 заявки за рефрешване (и това няма да забие сървъра)
3. Да си представим, че тези блондинки в един момент ги обхване работохоликата (много опасно заболяване) и те почнат да начукват по два записа в минута (нещо съвсем реално)
===================================
Да видим сега какво трябва да върши сървъра за да държи данните на всички блондинки актуални.
2х300=600 променени записа в минута или 10 записа в секунда (средно)
10*300=3000 заявки в секунда за да се държат актуални данните на блондинките.
Като включиш в сметката и мрежовия трафик, който се генерира при това, няма да остане много за полезна работа.

Така че не е невъзможно, но внимателно прецени наистина ли ти трябва.

Успех

opitai drug podhod! zapomni koi kakvo i koga? ne go replikirai i ne go obnovqvai, dokato vsi4ki "blondinki" ne sprat rabota "(prez no6ta)"...posle davai na vsqka "blondinka" neiniq profil( promeni) i ne se griji za gluposti.............taka 6te ima6 100_1000 profila....vsi4ki 6te sa dovolni....spisuka s kompanii 6te e pulen
( vinagi)...ni6to nqma da e iztrito . 4rez (parolata)6te znae6 koi (profil )da pokazva6 , i na kogo !
uspeh

Пич ...слушай са ква е истината.. аз отдавна съм го решил този проблем...
===
btw....БАЗАТА НЯМА ЗНАЧЕНИЕ....ако имаше то тогава всички трябваше да си купуват самолети а нямаше да търсят алтернативни решения с тирове микробуси и кораби например..ако ме разбираш...
===
ЗАПОМНИ...
В БАЗА ДАННИ НИКОГА НЕ ИЗТРИВАЙ В ТАБЛИЦИ ОТ ТИП РЕГИСТРИ И ПОДОБНИ...
единствено в темпорални таблици можеш да си го позволиш
===
Когато се каже мрежово приложение това означава че не може да се разчита на клиента... дори напротив ..търсиш начин ако някой зорлем иска да го счупи да не може..защото мераклии за зулуми колкото щеш...:))))
====
Във всяка такава такава таблица добавяш едно поле например STATUS.

При нов запис го сетваш 1 - ЖИВ
При изтриване го сетваш 3 - МЪРТЪВ (демек изтрит)


ПРИ РЕДАКЦИЯ ГО СЕТВАШ 2 - ЗАКЛЮЧЕН (досега не ми се е налагало но идеята е че първия който го хване за редакция го заключва и другите само го виждат. Ако въпросната блондинка го отвори за редакция и иде да си лакира ноктите при шефа то има няколко начина ....или чред друго допълнително поле да знаеш кога е започнала редакцията и да си избереш таймаут според ситуациата или чрез таймер в клиенската част формата за редакция сама да се изключва разбира се с подходящи съобщения....има и други решения

И така ..с това поле STATUS записа или е ЖИВ или... в "АРХИВ"... и ако спазваш идеологията на базите то няма да имаш загубени данни в релации поради изтриване...т.е. имаш документ доставка с вече избран доставчик и след 5 дена някой го изтрива(предполага се че в таблицата с документите доставчика присъства като ID а не като стринг както в някои велики програми като ДЕКАРТ или ORAK systems....) и когато се върнеш за справка на този токумент ...хоп ..доставчика липсва...
=====
Ако трябва да задълбаем то има не много труден начин да се запазят и всички редакци на определен запис и така ако доставчика преди година е бил с друг телефон а после го е сменил ...то тогава като извадиш справка за този доставчик ще можеш да покажеш цялата "история" на записите....

ОК???