ВладимирМ. Но таблица открыта другим пользователем в режиме Exclusive. Значит, данный пользователь идет со своим желанием далеко и надолго.
-просто кнопку еще раз нажмет

Во многом согласен, особенно по удалению, но :),
1) в проге около 30 ДБ и около 250 таблиц - а не в одной базе
2) при пересоздании запросов контролирется переоткрытие с этим же имннем, и не когда попало.
3) в проге нет ни одного жестко подвешенного view, от них отказались, а только генерируемые(class GenView) на ходу и на короткое время с уникальным именем
3) может я и ошибаюсь, но запрос прекрасно существует и редактируется и без запущенной таблицы(сохраняется потом).
4) проверка открытия , если нет, перезапрос
5) установлены level доступа, что и регулирует правила пользования.
*Конечно возможность пересечения userov при удалении остается, но она очень минимальна и неповлечет сбоя системы. Зато нам ненадо своих спецов ставить около каждой копии проги. (+ внутри доп.проги на автопроверку востановление и ремонт ДБ)

ВладимирМА теперь и признать это ошибкой не так-то просто. Даже самому себе. Зря что ли 1,5 года переписывал?

В первой версии было именно так как советуешь. Вообщето полностью переписывали 4 раза , ушло на это занятие 9 лет, сори уже 10, согласен с тобой этот вид работы с БД еще неидеален, но в данный момент для Fox этот вариант самый оптимальный (если не отказ от монопол реж открытия).
И так как это конструктор , админы клиентов могут сами устанавливать правила работы в своих компаниях; (если одновременно Userov на одной базе более 10), хотят-разрешат/запретят удаление или др. Самое главное для их мозгов(далеких от програмир) дан инструмент.

Посмотрите одну из комплектаций, а потом поговорим: http://]www.download.ru/?infoprogram=33110

Очень внимательно отнеслись к Вашим советам, сразу видно хорошего спеца по Fox, спасибо ВладимирМ!

ВладимирМ. Удаление - это исключительная (в смысле, достаточно редкая) ситуация.

Надо попробывать сказать это пользователям, интересно как они нам на это ответят .....

ВладимирМ....приложении. Ведь Вы делаете такие операции как резервное хранение, мелкий ремонт базы и т.д. и т.п. Вот в список подобных процедур и включить процедуру упаковки данных.

Нет, неделаем (прога сама все делает и проверку и ремонт и архивы и т. д.), к клиентам выезжаем только на установку новых блоков т.е. очень редко.
Мы исходили из того: прога должна обслуживать сама себя. А развивать(доробатывать) прогу могли простые Usera. Что нами и сделано.

для ВладимирМ
хотелось довольно коректно прокоментировать, но видно не суждено, отвечаю :

ВладимирМ По сути, Вы организовали "закат солнца вручную". Т.е. все то, что FoxPro делает автоматически, на уровне ядра системы, Вы вынуждены были повторить "вручную". И ради чего? Только ради того, чтобы не делать некие периодические операции?
Да, глючные места FoxPro пришлось обходить очень серьезно, особенно при переходе с 6.0 на 8.0. Они кое где забыли учесть приемственность! И чтоб больше от них не зависить ряд процедур было заменено. Зато у нас запускается прога на Linux(+Wine), а например 1C не запускалась и Ваша врятли пойдет ! Хотя замечу FoxPro мне нравится!

ВладимирМИтого, чтобы получить данные пользователь дает команду Select-SQL. Но чтобы выполнить эту команду надо открыть таблицы. Если другой пользователь открыл одну из нужных таблиц в режиме Exclusive, то первый пользователь выполнить эту команду не сможет в принципе. Получит сообщение об ошибке "access denide". После чего он должен повторять попытку открытия до тех пор, пока не "прорвется" к нужной форме. А это уже зависит от того, сколько времени таблица будет удерживаться в состоянии Exclusive и насколько хватит терпения у пользователя.
1)В режиме Exclusive таблицы закрыты почти всегда
2)Класс кнопки удаления видят только пользователи по Левел 1 а их на компанию обычно 3-4, они и устанавливают правила ввода данных.
3)Таблицы даже в режиме Shared открыты только при запросе и сразу закрываются

ВладимирМА это уже зависит от того, сколько времени таблица будет удерживаться в состоянии Exclusive и насколько хватит терпения у пользователя.Повторюсь, это все можно терпеть, пока объем данных (в байтах) относительно не велик и общая "заторможенность" системы особо не заметна. При росте размера базы код Вашего приложения начнет катастрофически разрастаться, чтобы довольно сложным программированием компенсировать кривизну идеологии, приводящую к системным тормозам приложения.
Только бестолковый аналитик держит все данные в "одной-двух" таблицах.Мы распределили нагрузку по вводу через промежуточные таблицы.А уж отделы договорятся когда им удалять , а когда нет!.
Кстати, часть данных за предидущие периоды уплотняются(раз в год или пять...)Пример: из 100т.строк остается 5т.строк(S), они физ переносятся в зеркала по отдельным таблицам.
Самое простое - гнать базу до млн-ов и не решать вопрос, как у Вас видно и сделано.

ВладимирМ Дальше на это накладывается масса проблем по организации процесса сохранения. Например, чтобы реализовать транзакцию, надо блокировать изменяемые записи. А это значит, что открыть таблицу в режиме Exclusive другим пользователем для упаковки будет невозможно. Т.е. тормоза будут не только при открытии формы, но и при ее закрытии. Терпеливые же у Вас пользователи
1)Вот поэтому полностью отказались от блокирования строки.
2)Также отказались от команды =TableUpdate(.t.) , буферизация таблицы колосально тормозит сохранение при больших объемах, неговоря уже об Update view. Используем Scat and Gather на не буф(1) таблицу.

ВладимирМ Поскольку, по Вашим словам, прога работает давно, значит, Вы уже "выдрессировали" пользователей. Они рассматривают постоянные задержки и проблемы с открытием форм, как нечто вполне естесственное.
Скажем так: Да, в чем то прав, действительно мы перенесли на Init все(query,view + index). Да, получаем торможение на 1-2сек дольше чем при обычной работе с Fox. Но , этим мы создаем совершенно независимое рабочее место и в разы увеличили скорость во время ввода данных т.к. оператор получает только необходимый и ограниченный набор данных! А у Вашей проги скорей всего тормозит в процесе, что гараздо хуже. В итоге у нас время ввода данных 2cek+X+X+X ? у Вас X+1+X+1+X+1 у кого быстрее

ВладимирМ Вы хотите сказать, что Ваши пользователи непрерывно удаляют только что созданные записи? Как же они вообще умудряются работать с Вашим приложением при таких тормозах?
Бред, даже коментировать не буду

ВладимирМ Если пользователи "не ведают, что творят", т.е. создают и сразу удаляют - надо "удалять" таких пользователей. Это значит, что пользователь вообще не думает о том, что именно он делает. Он ведь может и удалить то, что удалять не надо было...
Насколько я понимаю, программы пишутся для пользователей, а не для того чтоб им создавать неудобства. И я не говорил что у всех пользователей Левел1, следовательно и доступ к удалению

ВладимирМНадеюсь, Вы все-таки ведете лог действий пользователей. А то ведь Вы же крайними и окажетесь при "разборе полетов" кто когда и чего сделал...
Чаще в компаниях используется процедура анулирования, а не удаления(как хотят так и настраивают) т.е. при анулиров остается строка на месте с пометкой даты, время и логина.


ВладимирМ Rom_ew
Мы исходили из того: прога должна обслуживать сама себя. А развивать(доробатывать) прогу могли простые Usera. Что нами и сделано.
Это одна из тех идей, которая на практике не работает.
РАБОТАЕТ!

ВладимирМПо сути, он и выполняет роль администратора. А это значит, что этот человек рано или поздно, но обязательном придет к идее "вручную" дублировать все процедуры обслуживания приложения. Ну, не может сколько-нибудь сложное приложение не глючить. Не бывает так!
Да, глюки есть везде, но их может быть совсем не много зависит от продолжительности и качества теста и грамотности аналитка. А вот дороботать хотят все, эта возможность нами предоставлена, пусть развлекаются

ВладимирМ Во-вторых, "простые user-а" просто ничего не поймут. Не тешьте себя иллюзиями. Это Вы, с многолетним опытом разработки приложения считаете, что там все просто. По той причине, что Вы "видите" общую идеологию Вашего приложения. Т.е. понимаете зачем вот здесь была сделана дополнительная проверка, а вот здесь поставлено условие.
1)Поэтому мы серьезно доработали все объекты Foxa, они теперь сами подстраиваются друг под друга и БД - писать теперь почти не надо, кинул объект на форму дал ссылку и все.
2)Поэтому как "простые user-а", новички, и тем более профи всегда найдут как дороботать под их деятельность прогу.
3)Для профи: в EWEREST Construction предоставлены теже возможности как и в проекте Foxa (в RUN режиме), пусть творят что хотят и как хотят, толька экономия времени в 50 раз.
Мы сами уже делаем приложения не к Foxu, а к EWEREST: вместо 2-мес, уходит 3-4 дня для выполнение заказа на новый полноценный блок!

ВладимирМНа самом деле, "простой user" будет в ужасе от нагромождения кода. А то, что он у Вас весьма сложный и запутанный у меня нет никаких сомнений. Он "не видит" общую идею и не понимает, почему было сделано так, а не иначе, когда все можно было сделать по другому.
Да,код действительно не маленький за столько лет, но:
Код ядра недоступен и не виден, а сверху пусть пишут что хотят, всегда можно вернуться назад если ошиблись, это предусмотрено! +Прога сама за ними в большинстве случаев подчищает и подсказывает но не изменяет суть.
"простой user" в ужасе от Foxa, ему просто надо было сделать более узкую дорогу, чтоб глаза не разбегались и вроде получилось, правда много лет на это ушло.

ВладимирМЗначит, тому человеку, который решит заняться развитием Вашего приложения придется очень долго и вдумчиво изучать программный код не рискуя в нем ничего трогать.
Незачем , он почти ничего испортить не может, тем более если он хоть немного знаком с FoxPro.

ВладимирМИли же наоборот, "лепить" код "по месту", а потом вылавливать многочисленные баги и глюки того, что он налепил. Не сомневаюсь, что Вы уже сталкивались и с тем и с другим.
Он может вполне потренироваться на его UserForm, а потом код перенести в рабочие комплектации, Вы тоже врятли непроверенный код ставите клиентам! Тем более шанс на ошибку у него в 100 раз менше чем в проекте FoxPro, дорога более узкая!

Редко кто из авторов решился на полную перепись программы в 3 раз. А мы переписывали 4 раза, и вот токо теперь добились желаемого результата и вполне доволны. Переписывать полностью больше не планируем, не по тому что жалко еще 2-3 лет, а т.к. в итоге это оказался самый оптимальный вариант для FoxPro.

ВладимирМ, огромное спасибо за разговор, отвечать больше не буду, слишком много времени на это занятие уходит!

Полностью согласен.