Нужна помощь по TQuery.

← →
DimonS © (2005-08-31 09:16) [0]

Раньше почти не работал с запросами, поэтому подскажите, плз.

Как организовать в связке Query+DBGrid работу так, чтобы происходила запись в БД в реалтайме? Т.е. при выходе из ячейки происходила запись в БД нового значения. Писать запрос и переписывать всю строчку? Не желательно, в БД ок. 100 полей. Типа как это происходит при работе с TTable.

← →
Виталий Панасенко (2005-08-31 09:18) [1]

типа, Ф1 нажми.. и почитай...

← →
Anatoly Podgoretsky © (2005-08-31 09:18) [2]

Жалко пользователей, а то бы подсказал.

← →
dolmat (2005-08-31 09:46) [3]

Query>DataSource>DBGrid
||
\/
UpdateSQL

Так понятно?

← →
Ega23 © (2005-08-31 09:49) [4]

Не дело ты придумал, Димон.
Поверь.

← →
evvcom © (2005-08-31 09:55) [5]

> dolmat (31.08.05 09:46) [3]
> Query>DataSource>DBGrid
> ||
> \/
> UpdateSQL

Он же написал, что там 100 полей и запрос на update писать ему лень.
Присоединяюсь к Ega23 © (31.08.05 09:49) [4].

← →
dolmat (2005-08-31 10:07) [6]

>evvcom © (31.08.05 09:55) [5]
>Он же написал, что там 100 полей и запрос на update писать ему лень.
Не более минуты

← →
DimonS © (2005-08-31 10:14) [7]

то Ega23
А почему не дело? В чем плюсы-минусы? Просто раньше с БД работал через TTable, но по сети сложновато работает, блокировки и т. д. при многопользовательском доступе.

← →
Sergey13 © (2005-08-31 10:21) [8]

2DimonS © (31.08.05 09:16)
>Т.е. при выходе из ячейки происходила запись в БД нового значения.
А нафиг вообще это? Особенно если ушел на соседнее поле. При том что иногда (очень часто !!!) только совокупность значений нескольких полей валидна с точки зрения целостности данных.

← →
DimonS © (2005-08-31 10:31) [9]

Ну а как проще сделать? Типа того, что записывать при выходе из программы или с интервалом?

← →
Sergey13 © (2005-08-31 10:42) [10]

2[9] DimonS © (31.08.05 10:31)
>Ну а как проще сделать?
Делать надо не проще, а правильно. Тебе в [3] все уже сказали. Почитай справку по тем словам. Особенно по TQuery и TUpdateSQL.

ЗЫ: Если работаешь по сети, то стОит подумать о смене БД на серверную.

← →
dolmat (2005-08-31 10:43) [11]

>Ну а как проще сделать? Типа того, что записывать при выходе из программы или с интервалом?
Зависит от конкретной задачи. Выбирай сам.
>Просто раньше с БД работал через TTable, но по сети сложновато работает, блокировки и т. д. при многопользовательском доступе.
Меняй базы однозначно.

← →
Плохиш © (2005-08-31 11:07) [12]

> DimonS © (31.08.05 09:16)
> Раньше почти не работал с запросами, поэтому подскажите,
> плз.

Сначала приведи перечень литературы, которую ты уже проштудировал. Потом спрашивай, что там не понятно.
Халявщики(Партнёры) маст дай.

← →
Ega23 © (2005-08-31 11:16) [13]

Вот именно из-за частого появления таких вопросов я и считаю TTable со всеми клонами очень вредным компонентом.

2 DimonS
Вообще писать запросы напрямую к БД - не совсем правильно. Надо прослойку в виде хранимых процедур использовать.

← →
Sergey13 © (2005-08-31 11:24) [14]

2[13] Ega23 © (31.08.05 11:16)
>Вообще писать запросы напрямую к БД - не совсем правильно. Надо прослойку в виде хранимых процедур использовать.
Как минимум - спорно. Особенно для Парадокса и ДБФ. 8-)

← →
Ega23 © (2005-08-31 11:44) [15]

2 Sergey13 © (31.08.05 11:24) [14]
Как минимум - спорно. Особенно для Парадокса и ДБФ. 8-)

именно поэтому я и написал не совсем правильно, а не нельзя... :о)

← →
Sergey13 © (2005-08-31 11:48) [16]

2[15] Ega23 © (31.08.05 11:44)
В любом случае ХП на все - лишь один из равноправных вариантов. ИМХО.

← →
Ega23 © (2005-08-31 11:51) [17]

В любом случае ХП на все - лишь один из равноправных вариантов. ИМХО.

У тебя часто в клиент-серверных системах идут прямые запросы к таблицам? У меня - вообще нигде нет. Так, если что-то тестовое по-быстрому требуется накидать - там да, может прямой Select идти (ну или Insert какой-нибудь). А в конечных продуктах - только через ХП

← →
Sergey13 © (2005-08-31 12:06) [18]

2[17] Ega23 © (31.08.05 11:51)
>У тебя часто в клиент-серверных системах идут прямые запросы к таблицам?
Всегда. 8-)
Щас на работе ХП вообще под запретом (все на АПП сервере). И раньше никогда не использовал. В Оракле (в 8) вообще получать датасет из ХП несколько геморойно. Да и не дает это (ХП на все) никаких особых преимуществ.

← →
Anatoly Podgoretsky © (2005-08-31 13:09) [19]

DimonS © (31.08.05 10:14) [7]
И с TTable у тебя никогда не было такого.
Тебе про целостность данных уже написали, но это не все, а что ты будешь делать с откатом, ну не захотел пользовать редактировать, передумал, а ты уже все закинул в базу.

все на АПП сервере

Ха! А с АПП-сервером клиент у тебя как общается?

2[20] Ega23 © (31.08.05 13:11)
>Ха! А с АПП-сервером клиент у тебя как общается?
А какая разница? С ним, без него - запросы к БД всегда идут к таблицам, а не к ХП.

2 Sergey13 © (31.08.05 13:22) [21]
А какая разница? С ним, без него - запросы к БД всегда идут к таблицам, а не к ХП.

Разница есть, причём огромная.
Таблица - суть просто хранилище данных.
Клиент - общается с хранилищем данных на уровне бизнес-действий - бизнес-логики. Т.е. фактически клиент говорит - "Получить информацию о сотруднике", "Записать информацию о продажах" и т.п.
В случае полноценной трёх-звенной архитектуры роль транслятора бизнес-действий в физические запросы к конкретным таблицам играет сервер приложений. В случае двух-звенной - прослойка их ХП.

2[22] Ega23 © (31.08.05 13:52)
>В случае двух-звенной - прослойка их ХП.
Да почему это? Я вот и без этой прокладки спокойно обходился и обхожусь. И никакого дискомфорта - сухо и не пахнет. 8-)

Да почему это? Я вот и без этой прокладки спокойно обходился и обхожусь. И никакого дискомфорта - сухо и не пахнет. 8-)

При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу. А в случае работы с двумя разными СУБД - вообще плохо будет.
Я не говорю, что твой вариант - невозможен и порочен. Я говорю, что мой - более гибкий

2[24] Ega23 © (31.08.05 14:38)
ИМХО. "При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу" при любом варианте. И не сесть тоже можно при любом.

>Я говорю, что мой - более гибкий
Не стоит прогибаться под изменчивый мир
Пусть лучше он прогнется под нас.
(с) Пестня
8-)

2 Sergey13 © (31.08.05 14:57) [25]
ИМХО. "При изменении структуры таблиц (или при переходе на другую СУБД) можно некисло сесть в лужу" при любом варианте. И не сесть тоже можно при любом.

Была несколько раз следующая ситуация: Есть готовый модуль "Бюро пропусков". Из него можно давать разрешения на проход в разные Зоны и Точки. Но структура таблиц модели охраняемого объекта в процессе часто менялась (а если быть до конца откровенным, то сейчас я как раз занимаюсь тем, что переделываю её в очередной раз :)). Логика работы "Бюро пропусков" при этом не менялась ни разу. Во многих местах требовалось получить список зон и точек. Если бы в своё время я не ввёл ХП, которая этот список выдаёт клиенту, мне бы приходилось каждый раз в каждом Tquery, который обращается к модели менять текст запроса. Сейчас получается, что "Бюро пропусков" обращается к БД со следующим бизнес-требованием "Дай мне список зон и точек". А переписать ХП - это уже не так сложно.
Мне кажется, что это нечто сродни TAction. За одно и то же действие отвечает и пункт Главного меню, и пункт PopUp меню, и кнопка и сочетание горячих клавишей. Но само действие - одно и то же. Надо изменить логику работы действия - переписываешь код в одном месте. Надо изменить логику получения данных - переписываешь ХП, при этом не требуется ребилд клиента.

Всё - исключительно ИМХО. Просто привык к такому стилю.

2[26] Ega23 © (31.08.05 15:17)
Да все я понимаю, Олег. 8-)
Везде свои плюсы и минусы. Но ни у одного способа нет такого плюса или минуса, который перевесит все остальное.

>Если бы в своё время я не ввёл ХП, которая этот список выдаёт клиенту, мне бы приходилось каждый раз в каждом Tquery, который обращается к модели менять текст запроса
А этих запросов десятки и сотни? Этот список (сам по себе) - один запрос. Если в других запросах ты подтягиваешь этот список, то их скорее всего тоже надо будет править. Хоть в ХП хоть напрямую. А если список изменился по структуре. Цвет добавился например. Клиент не поймет нового поля в твоем списке без твоего вмешательства.

>при этом не требуется ребилд клиента.
Это самый убойный аргумент. 8-)

>Всё - исключительно ИМХО. Просто привык к такому стилю.
Аналогично. 8-)

Нужна помощь по TQuery. Найти похожие ветки