Добавить Calculated-поле в ран-тайм

← →
Ega23 © (2006-12-20 09:22) [0]

Возможно? Если сам DataSet создаётся в ран-тайм?

← →
Reindeer Moss Eater © (2006-12-20 09:27) [1]

Все создается в рантайм. Даже если есть иллюзия что что-то создается в дизайнере.

← →
Reindeer Moss Eater © (2006-12-20 09:36) [2]

Если вопрос не в "создать", а в "добавить", то нельзя добавить поле (любое, а не только calculated) в уже открытый датасет. Можно только в неактивный.

← →
Ega23 © (2006-12-20 09:38) [3]

> то нельзя добавить поле (любое, а не только calculated)
> в уже открытый датасет. Можно только в неактивный.
>

Вот вопрос именно в этом: достаточно ли просто Close сделать, или нужно ещё что-то?

← →
Reindeer Moss Eater © (2006-12-20 10:09) [4]

Нужно чтобы перед вызовом Open был заполнен список TFieldDefs всеми экземплярами TFieldDef.
Если датасет создается на рантайме, значит статических полей там нет.
Делаем Fielddefs.Update затем добавляем туда вычисляемое поле и открываем.

← →
Ega23 © (2006-12-20 10:18) [5]

> Делаем Fielddefs.Update затем добавляем туда вычисляемое
> поле и открываем.

ОК, спасибо, попробую...

← →
Anatoly Podgoretsky © (2006-12-20 10:26) [6]

> Ega23 (20.12.2006 10:18:05) [5]

Зачем пробовать, трясти надо.
Это законченый ответ, другого не требуется.
Единственно, если только отказаться от Calculated-полей в пользу Calculated-поле в запросе

← →
Ega23 © (2006-12-20 10:42) [7]

> Единственно, если только отказаться от Calculated-полей
> в пользу Calculated-поле в запросе

Не, там общая для многих модулей SP, если в ней ещё и Case с текстом для каждого поля-флага тащщить - никаких сил не хватит.

← →
clickmaker © (2006-12-20 10:47) [8]

> в ней ещё и Case с текстом для каждого поля-флага тащщить

UDF может?

← →
Anatoly Podgoretsky © (2006-12-20 10:50) [9]

> Ega23 (20.12.2006 10:42:07) [7]

Какой case, расчетные поля делаются в запросе Select A+B From или с применением служебных слов. Только не ясно можно тебе или нельзя. Эффективность расчетных полей в запросе много выше, поскольку пересчитываются только один раз.

← →
Ega23 © (2006-12-20 11:02) [10]

> Какой case, расчетные поля делаются в запросе Select A+B
> From или с применением служебных слов. Только не ясно можно
> тебе или нельзя. Эффективность расчетных полей в запросе
> много выше, поскольку пересчитываются только один раз.
>

Calculated поле ещё очень удобно использовать, например, при формировании текстового описания флаг-поля. Скажем, есть в выборке поле ProtoFl tinyint
0 - Не протоколировать
1 - Протоколировать иногда
2 - Протоколировать всегда

Я хочу в гриде видеть не числа, а текстовые описания этих полей. С другой стороны, включать в выборку ProtoFlStr=Case ProtoFl when 0 then "Не протоколировать" ... и т.д. тоже некузяво, т.к. нужно это только в одном месте, а сама SP используется в десятке мест.

← →
sniknik © (2006-12-20 11:14) [11]

Ega23 © (20.12.06 11:02) [10]
я в таком случае завожу служебную таблицу с описателями, запросы делаю с джойном... удобно. при вводе даешь значения из этой таблицы (т.е. получается не ввод а выбор из возможных вариантов). если нужно добавить флагов, делается даже без перекомпиляции программы... одним инсертом.
еще плюс в том что такое поле можно сортировать, если нужно, на клиенте, калькулируемое это не позволяет.

← →
Ega23 © (2006-12-20 11:22) [12]

> я в таком случае завожу служебную таблицу с описателями,
> запросы делаю с джойном... удобно.

Мысль интересная... А в значениях не путаешься? Я в том плане, что в одном случае (0,1) -> ("Нет", "Да"), в другом (0,1) -> ("Мужской", "Женский") и т.п.
Или ты группы вводишь, для каждой сущности - свой конкретный описательный набор, с жёсткой константой группы?

← →
sniknik © (2006-12-20 11:50) [13]

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

> Ega23 © (20.12.06 11:02) [10]

Это вообще задача для JOIN а не для расчетных полей.
Количество таблиц бояться не стоит, есть не просят, заводят таблицы и для одной записи, если по логике требуется.

> Количество таблиц бояться не стоит, есть не просят, заводят
> таблицы и для одной записи, если по логике требуется.
>

Да я и не боюсь, просто до такой штуки как-то не додумался.
Обязательно возьму (точнее - уже взял) на вооружение.

> Ega23 (20.12.2006 13:29:16) [16]

Обязательно бери, это профессионально и гибко, если в будущем потребуется сделать изменения, то они сведутся к изменению таблицы. И главное реляционно, а всякие case/if/when это обход реляционной теории.

Ну советов тебе надавали уже полно, а по сабжу, на всякий случай, все же скажу. Поскольку создавать хочешь именно в рантайм, то даже необязательно наследника оформлять как компонент. Хотя я в нашем проекте оформил в виде компонента, которого и кидаем на форму, не только ради сабжа, но и ради других реализованных необходимостей. Итак, в наследнике переписываешь метод:
procedure TMyDataSet.CreateFields; begin inherited CreateFields; if Assigned(FOnCreateFields) then FOnCreateFields(Self); end;
Идея, думаю, понятна. В обработчике можешь теперь добавлять любые кальк и лукап поля уже после того, как все остальные созданы, как в используемом по умолчанию.

procedure TMyDataSet.CreateFields; begin inherited CreateFields; if Assigned(FOnCreateFields) then FOnCreateFields(Self); end;

Гениально. Просто и гениально. Гемор только с множеством датасетов, но, с другой стороны, прицепить только к TADODataSet и пользоваться только им, это даже дисциплинирует...

Добавить Calculated-поле в ран-тайм Найти похожие ветки