| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
interbase(проблема ввода данных) [D7, XP]
kla$ © (2008-05-19 14:16:00)Создал бд. В ней 1 таблица. В делфе на форму кидаю IBQuery1,IBDatabase1,IBTransaction1, DataSource1 и DBGrid1. Прописываю:
IBQuery1.Database:= IBDatabase1;
IBQuery1.Transaction:= IBTransaction1;
IBDatabase1.DataBaseName:=прописываю путь;
IBDatabase1.DefaultTransaction:=IBTransaction1;
IBTransaction1.DefaultDatabase:= IBDatabase1;
DataSource1.Dataset:=IBQuery1;
DBGrid1.DataSource:=DataSource1;
Query1.active:=true;
Компилится норм, но почему то немогу вводить данные в DBGrid. Что я делаю неправильно. Буду рад любым советам, т.к. новичок в этом деле(.
MsGuns (2008-05-20 21:27:00) [61]>YurikGL © (20.05.08 21:00) [24]
>Ужс... если я бы так подходил, я бы не написал бы ни одного приложения...
Это говорит не в Вашу пользу. Я не знаю Ваших работ, но думается, они не отличаются ни скоростью, ни удобством, ни особой надежностью.
>Ну и где здесь неверное управление изменениями?
Неверное управление заключается, например, в отдаче "на откуп" IBX подтверждение изменений, выполняющихся типа автоматически (то есть, согласно insertSQL, DeleteSQL и ModifySQL, "походя", как Вы изволили выразиться, вставленным в ИБдатасет). Само по себе это "неверное" управление ничего плохого не представляет. До тех пор, пока Ваше приложение не станет критичным по "интерактивности"
>Есть задачи, есть базы... Причем здесь задачи?
Представьте, таки да ! Например, БД крупного предприятия. А на ней реализовано куча "задач"- подготовка производства, оперативное управление, управление качеством продукции, управление сбытом и т.д. Т.е. "База" - ОДНА, а "Задач" - куча.
"Есть в мире много, друг Горацио, что и не снилось нашим мудрецам" (c) ;)
>И причем здесь генераторы, как источник значений для первичного ключа?
Я Вам щас скажу страшную крамолу. Генератор вообще-то не есть источник значений ни для какого ключа. Он вообще не знает ни о каких ключах. А вот триггер, использующий генератор как механизм полученеия гарантированно уникального значения для ЭТОГО генератора, может использовать его именно как ИСТОЧНИК для определения ID добавляемой в таблицу записи.
>Читал в двух редакциях... Дальше что?
Не верится, ох, не верится.
>з.ы. давай конкретный пример, когда предложенный способ не подходит.
Вы все про редактирование в Гриде ? Я же Вам выше предложил сделать простой эксперимент. Если Вы реализуете его простым и привычным для Вас "батонокидательским" способом, то получите "слепых" клиентов. Если переделаете приложение таким образом, как это написано в вышеупомянутой книжице (только чур !, FIB не использовать), то клиенты буквально сразу "прозреют", т.е. будут видеть изменения, сделанные другими в нужный момент.
YurikGL (2008-05-20 21:00:00) [62]
> ОБЯЗАТЕЛЬНО. Нельзя программиста, разрабатывающего клиент-
> серверные приложения, и близко подпускать к компьютеру,
> пока он не усвоит азы. А транзакции - это легкие, печень
> и сердце любого скл-сервера.
Ужс... если я бы так подходил, я бы не написал бы ни одного приложения...
> Я этого не говорил. Я говорил то, что неверное управление
> изменениями на сервере могут привести к такому эффекту.
Ну и где здесь неверное управление изменениями?
> Вот есть некая БД. На сервере. И на ней крутится десяток,
> а то и полсотни разных ЗАДАЧ.
Есть задачи, есть базы... Причем здесь задачи?
> (например, удаление или изменение сложных "документных"
> объектов, сложные многоступенчатые расчеты или выборки,
> используемые многократно в разных приложениях, и т.д.) ВЫНЕСЕНЫ
> на сервер как часть БИЗНЕС-ЛОГИКИ.
И причем здесь генераторы, как источник значений для первичного ключа?
> Я все же настоятельно советую почитать "Мир интербэйз".
Читал в двух редакциях... Дальше что?
з.ы. давай конкретный пример, когда предложенный способ не подходит.
MsGuns (2008-05-20 16:12:00) [63]>YurikGL © (20.05.08 16:05) [21]
>Ты говоришь, что обновления в других клиентах появятся не сразу...
Я этого не говорил. Я говорил то, что неверное управление изменениями на сервере могут привести к такому эффекту.
>Вот я и говорю, что что бы появлялись - надо уведомлять.
Повторяю, я этого не говорил ибо это чушь ! Сервер никого и ни в чем не должен УВЕДОМЛЯТЬ. Это надо усвоить как дважды два, иначе не соит уходить с парадоксов и дибэйзов.
>Ну если речь идет о том, что бы модифицировать ПО написанное >неизвестным программистом, то может и нужно в триггере прописывать.
>Я же, когда пишу новое ПО, ничего не изобретаю, иду проверенным >быстрым способом и другим советую.
У меня такое ощущение, что вы читаете мои посты задом наперед ибо ничего из них не воспринимаете верно.
Какой ЧУЖОЙ программист ? Вот есть некая БД. На сервере. И на ней крутится десяток, а то и полсотни разных ЗАДАЧ. Писанных, вполне возможно, одними и теми же программистами, а возможно разными. Но это НЕ ИМЕЕТ НИКАКОГО ЗНАЧЕНИЯ. Просто часть логики (например, удаление или изменение сложных "документных" объектов, сложные многоступенчатые расчеты или выборки, используемые многократно в разных приложениях, и т.д.) ВЫНЕСЕНЫ на сервер как часть БИЗНЕС-ЛОГИКИ. И клиентские приложения используют эту логику явно или неявно. Я все же настоятельно советую почитать "Мир интербэйз".
MsGuns (2008-05-20 16:05:00) [64]>Вот как ты думаешь... такие подходы новичку нужны? с несколькими >транзакциями?
ОБЯЗАТЕЛЬНО. Нельзя программиста, разрабатывающего клиент-серверные приложения, и близко подпускать к компьютеру, пока он не усвоит азы. А транзакции - это легкие, печень и сердце любого скл-сервера.
YurikGL (2008-05-20 16:05:00) [65]
> Чевой-чевой ??? Я что-то говорил о каком-то извещении ?
Ты говоришь, что обновления в других клиентах появятся не сразу... Вот я и говорю, что что бы появлялись - надо уведомлять.
>Видите ли, существует т.н. БИЗНЕС-ЛОГИКА сервера, которая по определению
>более приоритетна, чем клиентская.
>Тот программист, который положил в тригер на сервере определение ИД записи,
>очевидно, что-то имел в виду этим сказать,
Ну если речь идет о том, что бы модифицировать ПО написанное неизвестным программистом, то может и нужно в триггере прописывать.
Я же, когда пишу новое ПО, ничего не изобретаю, иду проверенным быстрым способом и другим советую.
YurikGL (2008-05-20 16:02:00) [66]
> Несколько сложнее, ибо в технологии "одной длинной транзакцией
> читаем, другой, короткой, пишем" управлении транзакциями
> достаточно прозрачно. Ошибиться несколько сложнее.
>
Вот как ты думаешь... такие подходы новичку нужны? с несколькими транзакциями?
MsGuns (2008-05-20 16:01:00) [67]>эээ.... извещение со стороны сервера об обновлении данных всех >клиентов, это - совсем другая тема...
Чевой-чевой ??? Я что-то говорил о каком-то извещении ?
>А зачем его использовать в триггере? Если первичный ключ генерируешь >через generatorfield то никаких триггеров не надо.
Видите ли, существует т.н. БИЗНЕС-ЛОГИКА сервера, которая по определению более приоритетна, чем клиентская. Тот программист, который положил в тригер на сервере определение ИД записи, очевидно, что-то имел в виду этим сказать, и не ума дела проблемного прогаммиста, решающего лишь одну из ПРИКЛАДНЫХ программ, подвергать это ревизии. И тем более чего-то там изобретать, тупо используя предоставленные средой возможности. Рекомендую почитать Вострикова с Ковязиным - они весьма доходчиво и убедительно пишут.
MsGuns (2008-05-20 15:55:00) [68]Несколько сложнее, ибо в технологии "одной длинной транзакцией читаем, другой, короткой, пишем" управлении транзакциями достаточно прозрачно. Ошибиться несколько сложнее.
YurikGL (2008-05-20 15:54:00) [69]
> Но просто предложение - напишите такую простенькую прогу,
> редактирующю в гриде. Потом запустите ее на своем же компе
> в 2-3 экземплярах. Работайте с каждым поочередно и понаблюдайте
> - изменения, сделанные в одном приложении, далеко не сразу
> появятся во втором.
эээ.... извещение со стороны сервера об обновлении данных всех клиентов, это - совсем другая тема...
> Другие грабли могут случиться с вашим generatorfield, если
> генератор определяется на сервере и используется, к примеру
> в триггере.
А зачем его использовать в триггере? Если первичный ключ генерируешь через generatorfield то никаких триггеров не надо.
Sergey13 (2008-05-20 15:52:00) [70]> [15] MsGuns © (20.05.08 15:36)
Можно подумать на подобные грабли нельзя наступить при НЕгридовом редактировании.
MsGuns (2008-05-20 15:36:00) [71]>YurikGL © (20.05.08 15:30) [13]
Да, на клиенте все выглядит именно так - легко и непринужденно ;)
Но просто предложение - напишите такую простенькую прогу, редактирующю в гриде. Потом запустите ее на своем же компе в 2-3 экземплярах. Работайте с каждым поочередно и понаблюдайте - изменения, сделанные в одном приложении, далеко не сразу появятся во втором.
Другие грабли могут случиться с вашим generatorfield, если генератор определяется на сервере и используется, к примеру в триггере.
YurikGL (2008-05-20 15:31:00) [72]и еще generatorField прописать...
YurikGL (2008-05-20 15:30:00) [73]
> На самом деле все вовсе не так легко и непринужденно ;)
Седня пол дня этим занимался... легко и непринужденно! А если использовать lookup-поля и ehGrid то там вообще в гриде выпадающие списки рисуются...
з.ы. ну ессественно не забываем про то, что датасет нужно открыть, на грид дважды кликнуть, жимкнуть на кнопку, которая автоматом добавит все колонки, лишние колонки (с идентификаторами) удалить, у нужных сменить заголовок...
MsGuns (2008-05-20 15:27:00) [74]>Далее привязываем грид к датасорсу и все можно легко и непринужденно редактировать.
На самом деле все вовсе не так легко и непринужденно ;)
YurikGL (2008-05-20 15:11:00) [75]Кидаем IBDataset (ессественно с транзацкцией, коннекшном и датасорсом)
В selectSQL указываем select * from table
Правый клик на датасет->databse editor->жимкаем на generate sql и все применяем
Далее заходим в refreshSQL и проверяем сформировавшийся запрос. Частенько нужно указывать звездочку в select-е.
Так же не помешает пройтись по insertSQL, DeleteSQL и ModifySQL и проверить запросы там. Как правило, все нормально.
Далее привязываем грид к датасорсу и все можно легко и непринужденно редактировать.
kla$1 (2008-05-20 14:00:00) [76]
> Поддержка редактирования в гриде
не обязательно в Гриде, можно и в еdit'ах.
MsGuns (2008-05-20 12:20:00) [77]Поддержка редактирования в гриде должна реализовываться достаточно аккуратно и со знанием особенностей сервера и "движка". Новичкам не рекомендую этот способ.
Sergey13 (2008-05-20 08:15:00) [78]> [7] kla$1 (19.05.08 16:48)
> ппц, и так и сяк
Только не так как надо, см [2] последнее предложение.
kla$1 (2008-05-19 16:48:00) [79]ппц, и так и сяк....пробовал DBEdit'ы, но не получается отредактировать данные с БД. Когда использую DBEdit, то при одинарном клике в DBGride по записи, эта запись отображается в DBEdit(но вводить данные в него нельзя). А как сделать, что бы можно было через DBEdit(или просто Edit) редактировать записи которые отображены в DBGrid'e?
kla$1 (2008-05-19 15:44:00) [80]терь буду думать как можно редактировать данные которые я ввел...
| |
Страницы: 