Python-сообщество

Smar
Он конечно простой, рабочий на 100%. Но …

Я и писал про “но”… Плохой это вариант.

Smar
ри изменении в этой таблице (ловится на ID или по количеству строк(кому как нравится)) станции считывают последнюю строчку и сами решают что же с этим добром делать

Слишком много мороки и лишних сущностей. Проще смотреть значение, например, генератора. Но опять же, с каким промежутком по времени смотреть?
Второй вариант хорошо зарекомендовал себя ибо прост и надежен. Актуальная информация отображается и в таблице (можно закрасить ячейку, чтоб показать, что на момент операции над записью она уже изменилась), и в диалоге, и в конечном итоге, сама СУБД воспрепятствует некорректной операции. Далее. Я бы прятал таблицу, после каждой операции над деталью, показывая ее лишь при необходимости узнать реальное кол-во машин.

balu
Слишком много мороки и лишних сущностей.

Я тоже говорил что мой вариант мягко говоря не самый лучший.

balu
Я бы прятал таблицу, после каждой операции над деталью, показывая ее лишь при необходимости узнать реальное кол-во машин.

Это кажется самый оптимальный вариант. При этом варианте данные грида будут всегда свежими.
Беда в том, что по условиям заказчика это может быть не выполнимо. Все привыкли к интерфейсу в котором все и сразу. Моду диктуют 1С и иже с ними. С такими монстрами трудно поспорить. Но если сделать все красиво и по современному почему бы и нет.

application server.
Все запросы к базе данных делаются к нему (в кастрированном варианте - только те, которые относятся к машинкам).
Этот сервер представляет собой демон (или сервис в терминах винды). Способ общения - от XMLRPC до специфического для питона RPyC.
Платформа - на ваш выбор (люблю twisted).
Поскольку можно на сервере запоминать клиентов, то можно наладить и обратную связь.
Если грамотно все построить, рубить отвалившихся, обрабатывать пинги и т.д. - получится красиво.
Подход предполагает знание довольно многих вещей из области распределенных систем. Чуть больше, чем просто клиент-сервер.
Рассказать все сразу, тем более не видя проблемы в целом (и существующего кода) - невозможно.
Посему, вероятно, предложенную заумь не стоит рассматривать.
Такая система будет работать, и написать ее не очень долго. Но не очень просто.

Андрей Светлов спасибо!
Этот сервер недостающее звено в моей схеме. Он позволяет решить многие проблемы в организации сетевых бд.
Такой подход на сегодняшний день считается передовым. Более подробно о организации распределенных сетей можно прочитать по этой ссылке http://www.citforum.ru/cfin/prcorpsys/infsistpr_02.shtml