![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
DBGrid и StringGrid [D4]
mate © (2003-01-14 10:03:00)Как быстро можно перекидать данные из BdGrid пулученные по запросу Query в соответствующие ячейки StringGrid.
gek (2003-01-14 13:17:00) [1]В принципе можно делать как сказал stone © (14.01.03 13:01)
единственное это для сложных запросов работать не будет
dimis (2003-01-14 13:02:00) [2]или используй TClientDataSet
stone (2003-01-14 13:01:00) [3]
> Потому что я не могу кликнув мышкой в ячейку DBGrid бысто
> поменять (0,01 сек) её содержимое, а в StringGrid могу
TDBGrid и TStringGrid наследуются от TCustomGrid и редактирование ячеек там одинаково. Кроме того я сомневаюсь, что ты сможешь вручную поменять значение за 0,01 сек где угодно.
> данные в DBGrid из Query и мне для изменения данных надо
> писать SQL запрос и обновлять Qiery.
Достаточно у Query установить свойство RequestLive=True и ничего писать и переоткрывать не надо
> Теперь понятно...?
Мне лично не понятно
dimis (2003-01-14 12:57:00) [4]mate ©
не зачем перекидывать данные из обного места в другое
Используй TUpdateSQL
AM (2003-01-14 12:57:00) [5]Можно сделать так как сказано в
>> BorisUK © (14.01.03 12:10)
Но только чуть-чуть подругому
запонять из полного (в 10000 записей) Query в StrinGrid по частям, на сколько видно пользователю, потом по мере скролинга запонять оставшуюся часть(в любом случае надо будет по строчке, по очереди... ), и так до конца, т .е. не надо дополнительных запросов к БД. По крайней мере из стандартных компонентов - это один подходящих для тебя я думаю...
но тут втоет вопрос если пользователь сразу захочет пойти на самый конец набора данных ... тогда начнутся тормоза...
В принципе если подождать годика два, когда выйдет
Pentium-5 5000MHz - то все это будет очень быстро работать :))
mate (2003-01-14 12:55:00) [6]gek ©
Потому что я не могу кликнув мышкой в ячейку DBGrid бысто поменять (0,01 сек) её содержимое, а в StringGrid могу.
т.к. данные в DBGrid из Query и мне для изменения данных надо писать SQL запрос и обновлять Qiery.
Теперь понятно...?
dimis (2003-01-14 12:55:00) [7]>>mate © бsстро перекинуть не получится
надо искать дргой путь
что мешает редактировать в DBGride?
stone (2003-01-14 12:52:00) [8]2 mate ©
То, что ты хочешь, быстро не получиться.
gek (2003-01-14 12:48:00) [9]Честно говоря,я так и не понял зачем данные перекидывать?
mate (2003-01-14 12:45:00) [10]а в ответ тишина...................
mate (2003-01-14 12:30:00) [11]Мне главное быстро перекидать данные, а сохранять их хоть 9999 и хоть N часов. Главное их получить.
Дайте же хоть кто-нибудь ответ на этот вопрос, плиззззззззз.
AM (2003-01-14 12:22:00) [12]>>Изменения мне сохраниять только те которые были рельно
>>изменены. И там нет ограничений по времени. т.е. если user
>>ничего не менял то ничего и не сохраняется.
Я так понял, что изменения будут заносится в БД в конце сеанса работы пользователя(?)Тогда думаю что это будет очень долго, так как тебе предется следить где и как были произведены изменения и производить их поочереди. А если их будет более 9000 ?
А если посуществу, то в данном случае, если DBGrid тебе не подходит и все его предки тоже, то тогда надо писать свой копонент. Перевод в StringGrid - это не лучшее решение, так как встоет задача обеспечения обратного процесса.
Наталия (2003-01-14 12:22:00) [13]Уууу! Как всё запущенно! Какой-то у тебя всё-таки в корне неверный подход к обработке данных, имхо. Если это такая критичная система реального времени, то, судя по твоим вопросам, группа захвата чаще всего будет приезжать к тебе...
mate (2003-01-14 12:11:00) [14]Max Zyuzin ©
Изменения мне сохраниять только те которые были рельно изменены. И там нет ограничений по времени. т.е. если user ничего не менял то ничего и не сохраняется.
А частота 100 Гц - это уже проблема операторов, они деньги за это получают.
BorisUK (2003-01-14 12:10:00) [15]Отображай на экран только часть данных...
Сделай кнопку далее>> (или по событию скролинга)
По ней подбавляй следующую часть.
и так далее.
Процедура перелопачивания данных из Query в SG будет работать выдавая данные по-частям, по доп запросу.
Max Zyuzin (2003-01-14 12:04:00) [16]Ответь плиз на мой вопрос - тебе изменения надо назад сохранять или нет?... К тому же думаю не сможет кликать мышью и изменять данные с частотой 100 Гц
mate (2003-01-14 12:04:00) [17]Наталия ©
Через 20 сек срабатывает сигнализация и высылается группа захвата.
А если серьёзно просто надо.
mate (2003-01-14 12:00:00) [18]Sergey13 ©
10000- это как раз и есть конкретизированный запрос.
Так что мне делать.?
Sergey13 (2003-01-14 11:57:00) [19]2mate © (14.01.03 11:54)
А ты определись - нужно юзеру ОДНОВРЕМЕННОвидеть >10000 записей или нет? И многое станет ясно. Запросы то ведь можно (и нужно!!!) конкретизировать.
Наталия (2003-01-14 11:57:00) [20]А зачем тебе на скорость это делать?
Параметры запуска баллистических ракет?
Обгоняешь что-ли кого-то? :) А если не успеешь за 20 сек - то что? Зачем вообще нужно визуализировать 10000 записей? Пользователь всё равно не сможет с ними работать. Тем более за 0,01 сек. :0)