Вообщем есть следущая проблема:
Написан BDE клиент, работает все нормально, когда он работает один, а если еще парочку клиентов запустить, то капец deadlock-и достают.
Мое видение проблемы:
Дело в том что используется компонент TQuery которые просто используются для отображения таблиц, все операции выполняются с помощью хранимых процедур, и врядли возникают deadlock-и там, дело в том что есть основание полагать что TQuery использует курсор на сервере, причем курсор видимо read only, который блокирует записи и не дает выполнятся хранимым процедурам, а почему я так решил что он использует курсор на сервере, то потому что при движении по таблице он каждый раз дергает сервер для зачитки даных.
Когда то я использовал ADO там можно указывать тип курсора клиентский или серверный, и когда указываешь клиентский все работает класно, а серверный это аналог работы TQuery притармаживает по понятным причинам...
Внимание вопрос: Можна ли в TQuery установить клиентский курсор, если да то как, или другие предложения которые позволят развязать конфликт BDE Client-ов...
Жду ваши предложения...

Подробнее пожалуйста...
А как через Stored Procs???

Это я знаю, меня интересует как отображать данные через Stored Procs, как это делает TQuery через DataSource когда его цепляешь к Grid-у

А если нужно отображать связанные таблицы???

Че-то глючит пишет:
... raised exception class EDBEngineError with message
General SQL error
ct_send(): user api layer: external error: this routine cannot be called because another command structure has results pending. Process stopped ....

Вообщем это вызов еще одной процедуры которая имеет параметры из основной таблицы и по идее должна возвращать подчиненную таблицу которая отвечает параметрам...
Наверно уже перетрудился...

Да нет же вложенного вызова там нету...

Схема работы такая:
1. Вызывается хранимая процедура, которая вовращает главную таблицу
2. Есть DBEdit который привязан к Grid-у в котором отображается главная таблица
3. Потом DBEdit->Text передается как параметр в следущую хранимую процедуру, которая возвращает подчиненную таблицу в другой Grid в соответствии с параметром
4. Error при открытии второй хранимой процедуры

???

Он используется как параметр второй хранимой процедуры,
а не для редактирования
Просто когда юзер двигается по главному гриду, я через DBEdit знаю на какой он строке стоит, чтобы выбрать с помощью другой хранимки выбрать записи которые подчинены записи из главной таблицы , таким образом должно быть отображение 1->n.

И смысл этого FetchAll-а???

Читаю справку...

Не знаю че там за лажа, но FetchAll() помог избежать ошибку BDE Error, а насчет множества пользователей еще не знаю....

А теперь эту фигню пишет уже в среде разработки, но в ней же нельзя выполнить FetchAll...

ct_send(): user api layer: external error: this routine cannot be called because another command structure has results pending.

Не могу изменить теперь ни одного обьекта в DataModule...

Да уже полегчало, уже вроде бы все работает...
Но есть прикол в том что когда запускаешь много клиентов, то первый открытый клиент работает быстрее чем остальные, а остальные че-то притормаживают...
Причем смотрю в процессах приоритеты их равные.
It's paradox...???

В принципе я был с самого начала прав на счет клиентского курсора, только не знал как его делать, оказалость FetchAll возвращает данные на клиент не держа при этом курсор на сервере, при этом приложение значительно быстрее работает, так как ему не приходится все время дергать сервак, единственный недостаток этого подхода является работа с мнимыми данными, например пока я редактирую запись ее уже кто нибудь удалил, и че делать??? От этого меня раньше предохранял серверный курсор, так как он блокирует записи... но в принципе меня сейчас устраивает и клиентский курсор, а дальше будем думать, может чего-то и придумаем...

To be continued...

За ADO я обеими руками, но я работаю под Sybase и там ADO глюк на глюке, даже connect глючит, пишет
ошибка: разрушительный сбой(я лично такого еще не видел), поэтому решил не рисковать и писать все на BDE...