Уже похожее спрашивал, но результат не помог. Перефразирую.

1. Необходимо с сервера Oracle в DBGrid вывести результат запроса в котором происходит обращение не к таблице а к представлению. - сделано

2. Вводится данные будут с помощью хранимой процедуры с отдельной формы, т.е. оператор открывает форму с гридом, в котором выведены имеющиеся данные. Далее нажимает кнопку "Добавить" и открывается новое окно с полями для ввода. данные из этих полей будут переданы в хранимую процедуру выполняющую необходимые проверки и сохранение. - сделано

3. Если данные сохранились нормально, процедура возвращает, например: True. - сделано

4.Если процедура возвратила True, то данные в гриде обновляем не с сервера (что бы не загружать сеть), а дописываем новую строчку в которую впишуться данные ранее передаваемы на сервер (например сохраненные в переменных) - В ЭТОМ И ВОПРОС

Используются компоненты BDE. На другие начальство пока не согласно. Единственное, что вместо DBGrid планируется использовать cxGrid из ExpressQuantumGrid

было бы неплохо простенький примерчик

 Интересный вопрос. 
 Могу сказать сразу, что задача далеко не тривиальная и простеньким примерчиком тут не обойтись.
 Как мне кажеться грид тут не причем, надо создавать наследники TTable, TQuery (или TDatSet) и разгребать в них  Refresh(TTable) и может что еще. Тоесть надо заставить обновлять их только указанную часть данных. 
 Но как тогда быть с несколькими пользователями. Это что - один добавил строку и увидел её, а другой после добавления своей строки только её и узрел? Не логично получаеться.

 Снечала я бы оценил размер запроса и как часто вводятья данные и обновляеться информация у пользователя. Таким образом вычисляешь обьем трафика в секунду. Можно даже увеличить его на порядок (это я конечно загнул), ведь помимо результатов запроса по сети будут лететь системные вещи того же BDE.

 И только после подобного анализа можно оценить стоит ли это того, что бы выдумать себе головную боль.

 Но это всего лишь мое видение проблемы.

Точно сейчас не помню, но примерно проверялось. в представлении ~300 тыс. записей, в результате выполнения запроса получено ~80-90 тыс. записей. Время выполнения 17-20 сек. Если после ввода каждой записи оператор будет ждать обновления 20 сек., то сколько ж он тогда за день введет?



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

данный алгоритм реализован в связке VFoxPro - Oracle, там для этого используется курсор. а вот есть ли такое понятие в Delphi я не знаю :(

  По-поводу курсора я тоже к сожалению не знаю.
  Но описанный подход лично я считаю немного некорректным. "Барабанить" такое количество записей и заставлять пользователя ждать 20 секунд я бы не стал. Надо менять подход.
  Когда ты закачиваешь на машину 80-90 тыс записей ты впринципе жрешь ресурсы мащины - вроде как жалко, тем более оператор никогда не будет их все просматривать.
  Я не так давно работал с одной базой, так под нее на фирме один мужик сам написал наследника TDatSet, а именно свой Table. Так вот, этот компонент загружал только часть записей (100~200), а остальные подкачивал порциями по мере прокручивания грида - идеальный подход. И его рефрешить не составляет труда - доли секунд. К сожалению этот компонент заточен только под эту базу (MSM).

 Если не чувствуешь в себе силы писать компонент (я сам пока не готов   ), предлагаю альтернативу делать запрос только на какой - то участок индекса, например, если индекс - фамилия то загружать только на одну букву. Когда оператор вносит данные ты смотришь на какую букву начинаеться индексное поле новой записи и именно этот участок базы подкачиваешь в запросе.

 Может этот подход для твоей задачи и не годиться, я не знаю всех начальных условий, но на мой взгляд это лучше чем "барабанить" 90 тысяч записей.

Писать компонент сам не готов.
Вроде разобрался. 
Используются компоненты: Database1, Datasource1, Query1, UpdataSQL1.
В DataSource Dataset:=Query1
В Query1 установил CahedUpdate:=true; UpdateObject:= UpdateSQL1;
В UpdateSQL1 ничего не настривал.
Для изменения полей в текущей строке после выполнения храним. проц.  использую, только присваиваю не строку('Новый товар'), а соответствующую переменную



Таким образом данные записываются в кеш у клиента, при этом появляется временный файл *.MB

При таком использовании, могут возникнуть, какие то баги?

 Посмотри как поведет себя программа если накопить временный файл, а потом закрыть корректно или не корректно приоржение или разорвать связь с базой. Если после таких трюков твои компоненты отработают эти *.MB - файлы и целостность базы востановиться. Тогда спи спокойно.
Если же нет ......
Мне так делать не приходилось. Посоветовать не могу, сори.

дело в том, что считывать данные из жтих файлов, в случае некорректного отключения от БД или выхода из программы считывать не нужно. Т.к. данные в них попадают только после записи на сервер, а при корректном выходе они автоматически удаляются. На случай некорректного выхода (что б не засорять директорию) проверяю наличие таких файлов, и удаляю.
Правда присутствуют все равно тормоза, а с чем связано не знаю. при выборке 130 тыс. записей происходит притормаживани 3-7 сек когда вношу изменения. Причем в Диспетчере задач не отображается изменение использования сети, а происходит всплеск нагрузки на процессор. Что это перерисовка грида или UpdateSQL пытается выполнить какие то действия?