> Возможности удаления записи не должно быть!

это ТС сказал?

> [194] Anatoly Podgoretsky ©   (17.12.11 19:27)
> записи не удаляются никогда, а
> заносятся только по окончанию связи, то есть только завершенные
> связи, а
> завершенной связь считается после обменая информацией о
> сигнале (RST).

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

> Inovet  (17.12.2011 20:05:21)  [201]

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

> Врёшь. Чтоб номер стал правильным, нужно Post сделать


Вру. Не спорю - вчера ночью когда правил - не туда вписал определение номера связи - нужно было конечно на афтерпост вставлять)))


> Не прошло и недели, как ты сподобился поделиться деталями
> предметной области.


Да не, я предметную область уже недели как 3 обрисовал))))

Ладно, пока вопрос о номере оставлю открытым - сделаю чтоб в статус баре высвечивался номер. В принципе вопрос для меня сейчас не столь принципиальный.
Меня сейчас больше интересует вопрос поднятый мной в теме
ADO+DataSet+DBGrid - быстро обновить данные.
Сейчас еще раз просмотрел аналогичную моей программу - там какая то просто финаминальная скорость обновления данных в табличном виде. По ходу применен какой то не стандартный компонент. Пока не пойму какой.

есть предложение забить на Аксесс, провайдеры данных, и взяв sqlite через api-шный интерфейс самому рисовать табличные данные, где надо и когда надо, и на чем надо :)

> [204] antonn ©   (17.12.11 22:59)
> sqlite

для полноты и на sqlite забить. Всё самому написать.

зря стебешься

> Пока не пойму какой.
мозг?

> есть предложение забить на Аксесс, провайдеры данных, и взяв sqlite
есть предложение начать учится хоть чему нибудь. а не перебирать компоненты, бросая все с чем что-то не получается. все в итоге бросишь, ничего не останется.

> есть предложение начать учится хоть чему нибудь.

ой, а "безкомпонентные методы доступа" вообще так много новых перспектив для изучения открывают :)

> есть предложение начать учится хоть чему нибудь.


зря ты так. у меня в программе кроме БД и  DBGridEh никаких сторонних компонентов нет - все свое, включая работу с инет, ком-порт и т.п. Я вообще ПРИНЦИПИАЛЬНО против сторонних компонентов. Только то, что действительно необходимо - БД самому все же так вот не напишешь. Хотя и было желание)))

есть, нет сторонних компонент, какая разница? если у тебя прямо таки уверенность. что скорости добиваются не знанием работы/методов/особенностей технологии/алгоритмов/т.д. а сторонними компонентами
> там какая то просто финаминальная скорость обновления данных в табличном виде. По ходу применен какой то не стандартный компонент. Пока не пойму какой.

а у второго "ученого" прям сразу "рецепт", а взять и поменять, типа не получилось как надо "пройдясь по верхушкам", без углубленного изучения, а пофигу, возьми другой. а не получится с ним (а точно не получится с таким подходом), тогда третий. и нормально нечего знать не будешь.

капетан?

я за цыфирки.

> там какая то просто финаминальная скорость обновления данных
> в табличном виде. По ходу применен какой то не стандартный
> компонент. Пока не пойму какой.


Ты уверен, что там TDBGrid?  :)

> Ты уверен, что там TDBGrid?


Проанализировав екхешник, пришел к выводу что там DBGridEH - но не уверен.


> как надо "пройдясь по верхушкам", без углубленного изучения


Ну вообще то я здесь как раз и занимаюсь: углубленным изучением предметной области.
И вообще - злой ты какой то)))

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