|
|
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Возможна ли обычная фильтрация (через filter) по lookup-полям? TTable, похоже, отрицает такую возможность: авторProject Project1.exe raised exception class EDatabaseError with message 'Field 'cex' cannot be used in a filter expression'. Process stopped. Use Step or Run to continue.TOracleDataset/DOA гавкать не гавкает, но положительного результата не выдает - выдаёт пустой набор данных. Фильтровать по совету автор"How can I filter on a lookup field in a dataset? Answer : You cannot use the lookup field's name in the filter string, but you can use an OnFilterRecord" можно, но как-то муторно - весьма затруднительно в сопровождении, нет универсальности. Потестировал в очередной раз свой любимый ДОА, сделал "на коленке" такой пилотный вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Конечно, для GetCalcFields(PChar(FFilterBuffer)) еще желательно проверять, есть ли необходимость в вызове этого метода (наличие "lookup field in списке полей в фильтре"). Ясно, что фильтрация будет медленнее, чем по обычным полям. Но вряд ли медленне, чем с использованием OnFilterRecord. ---------------------------------------------------- Хочется услышать мнение заинтересованных коллег. Стоит ли ковырять в эту сторону? Писать письма в AllRound уже надоело, всё бестолку - похоже, этот продукт им перестал приносить реальные деньги уже давненько. ---------------------------------------------------- Главная цель разработки: универсальный механизма локальной фильтрации без разделения полей на обычные, калькулируемый и lookup - т.к. юзеру в конце концов пофиг, какие они на самом деле. ---------------------------------------------------- Прошу в данном топике не предлагать осуществление фильтрации средствами БД - как это делается, я знаю вполне прилично - все граничные условия на сервере задаём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2008, 01:19:22 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymx> Но вряд ли медленне, чем с использованием OnFilterRecord. Когда-то давно когда у меня тоже всплыла подобная мысль, я ответил себе, что все это мелочи, не стоящие внимания, поскольку фильтруются в абсолютном большинстве случаев достаточно небольшое количество данных и разница между обработчиком OnFilterRecord и стандартной фильтрацией будет минимальна. И небольшой тест это подтвердил. andreymx> Хочется услышать мнение заинтересованных коллег. andreymx> Стоит ли ковырять в эту сторону? На мой взгляд - скорее нет, если это разовая задача. Если же это задача достаточно часто встречающаяся (и иные надстройки Вы уже делали) и хочется какой-то универсальности - то стоит. andreymx> универсальный механизма локальной фильтрации без разделения полей на обычные, andreymx> калькулируемый и lookup - т.к. юзеру в конце концов пофиг, какие они на самом деле. На мой взгляд, проще и правильнее реализовать в механизме/компоненте фильтрации (GUI или где-то рядом) - т.е. когда пользователь выбрал лукап-значение, добавлять в выражение фильтра условие строку поле_кода_лукапа + операция + значение_кода_лукапа. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2008, 02:23:53 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустамandreymxуниверсальный механизма локальной фильтрации без разделения полей на обычные, калькулируемый и lookup - т.к. юзеру в конце концов пофиг, какие они на самом деле. На мой взгляд, проще и правильнее реализовать в механизме/компоненте фильтрации (GUI или где-то рядом) - т.е. когда пользователь выбрал лукап-значение, добавлять в выражение фильтра условие строку поле_кода_лукапа + операция + значение_кода_лукапа. Это реализовано и уже давно, но наши пользователи хотят полной поддержки - скажем, фильтр по подстроке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2008, 09:09:41 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxскажем, фильтр по подстроке. Ясно. В таком случае делать из лукапов "настоящие" поля - например, их выборкой join-ом со справочником. Впрочем, это, конечно, скорее воркэраунд. P.S. Да, как известно, я не поклонник лукап-полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2008, 16:39:45 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxХочется услышать мнение заинтересованных коллег. Стоит ли ковырять в эту сторону?Это тебе виднее - надо не надо. Но скорее всего будет работать. andreymxПисать письма в AllRound уже надоело, всё бестолку - похоже, этот продукт им перестал приносить реальные деньги уже давненько. Я об этом говорил еще 2 года назад. Обороты от PSD в десятки раз выше, чем от DOA. andreymxГлавная цель разработки: универсальный механизма локальной фильтрации без разделения полей на обычные У тебя все получится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2008, 18:11:39 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievДмиорий, а как в ANYDAC уживаются filter+lookup? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2008, 10:29:07 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxа как в ANYDAC уживаются filter+lookup? Явно - так же как и в DOA, т.е. никак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2008, 18:44:13 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefievandreymxа как в ANYDAC уживаются filter+lookup? Явно - так же как и в DOA, т.е. никак.А на будущее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2008, 21:32:25 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymx Ну что бы и нет ... Только сначала подумаю на введением альтернативы lookup полю. Они ограниченные и не самые эффективные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2008, 09:22:12 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefievandreymxсначала подумаю на введением альтернативы lookup полю. Они ограниченные и не самые эффективные.Ну да... сильно зависит от количества строк lookup-dataset-а. Если он не проиндексирован по ключевым полям в мемори ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 09:50:13 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxНу да... сильно зависит от количества строк lookup-dataset-а. Если он не проиндексирован по ключевым полям в мемори Ну там больше аспектов над которыми стоит подумать ... 1) Если lookup2 поля сделать fkInternalCalc, то их можно будет вычислять только раз - при первом чтении значения lookup2 поля. Далее вычисленное значение сохраняется в буфере записи вместе с остальными полями. Существенно ускорит навигацию (гуляние вверх, вниз, влево, вправо по датасету с кучей lookup полей). 2) Если lookup2 поле уметь привязывать к полю c.Name в следующем запросе: Код: plaintext 1. Это может ускорить lookup2 поля, где lookup датасет имеет мноооого записей. 3) LookupResultField - одно поле ? Не густо ... Неплохо было бы ввести форматную строку, например: Код: plaintext в Lookup source или типа того. Это позволит динамически строить необходимые запросы к справочнику. Что в свою очередь позволит: - иметь режим вычисления Lookup2 поля прямым SELECT ... FROM ... WHERE <PK> = :Val; - приделать развитой LOV к Lookup Source; - реализовать QBF, который сможет строить результирующий запрос и по Lookup2 полям ну и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 10:17:47 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Главное, чего не хватает нам в lookup/picklist - это возможность создания зависимых выпадающих списков. Т.е. главная рашифровка, предположим, по pred+cex; а в строке грида при уже введенном pred чтобы выпадали только строки с таким pred. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 10:58:03 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxГлавное, чего не хватает нам в lookup/picklist - это возможность создания зависимых выпадающих списков. Это делается MasterSource в (4) случае. Собственно то, о чем я тут говорю, было реализовано лет 10 назад для БДЕ - теперь думаю затащить в AnyDAC ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 11:02:06 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Да, это очень неоднозначная проблема - стоит ли для каждой строчки дёргать БД. В общем случае - я против. Аргументы всё те же: нагрузка сети, БД, +возможно, DbLink, + возможность получения несогласованных данных... Хотя в некоторых случаях вполне ускорит работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 12:36:23 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxДа, это очень неоднозначная проблема - стоит ли для каждой строчки дёргать БД. Да, неоднозначная - это точно. Например, есть справочник материалов (что-то в районе 200,000 записей). Есть строки заказа (штук 5-10 записей). 0) При стандартном lookup поле - все 200,000 засосутся в память. Что будет задержкой в несколько секунд, съеденными 50-70Мб памяти и хорошей нагрузкой на сеть, когда 100 чел. с утра дружно начинают работать. Варианты оптимизации: 1) каждая станция дернет свои 10 SELECT WHERE PK=:Val. Вобщем-то копейки ... Но будет кошмар, если надо выбрать X * 100,000 записей. 2) грузится не весь справочник материалов, а его подмножество / раздел. Предположу, что работает плохо, так как могут быть в одном заказе и плоскогубцы и валенки ... 3) выборка основного набора данных идет rowset'ами по X записей (в AnyDAC - 50 по умолчанию). Можно после выборки очередного rowset собрать все RefID и выполнить SELECT WHERE PK in (id1, ..., idN). 4) выбирать основной набор данных уже сдойженный со справочниками. Сервер достаточно быстро отработает такой запрос. Но будет ужастик для программиста, если 50 справочных полей. Кстати, а как там Forms реализует LOV ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2008, 13:37:11 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
В Direct Oracle Access 4.1.1 я сделал так Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2012, 13:08:24 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
andreymxпредположим, по pred+cex; а в строке грида при уже введенном pred чтобы выпадали только строки с таким pred.Прошу прощения за некрофилию. Данная задача была решена? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2017, 18:44:34 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустамandreymxскажем, фильтр по подстроке. Ясно. В таком случае делать из лукапов "настоящие" поля - например, их выборкой join-ом со справочником. Впрочем, это, конечно, скорее воркэраунд. P.S. Да, как известно, я не поклонник лукап-полей.+500. Я делаю обычные поля. А для полноценной имитации лукап-поведения в гриде, возвращаю из лукап-формы в датасет два значения: ключ и текст (благо, что файрДАК умеет "редактировать" нередактируемые поля). Если запись запостить, то текст обновится уже с сервера. Если edit отменить, то вернется старое значение текста. И лукап-форма при этом полноценная. Есть поиск, фильтрация, создание новой записи и многое другое, чего заведома нет в лукап-комбобоксе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2017, 10:41:07 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
LSV+500. Я делаю обычные поляЗадача: в ячейку грида воткнуть комбобокс с предопределенным выпадающим списком. Раньше это было сделано через позиционирование лукапкомбобокса на ячейку грида. Думал убрать комбобокс и сделать лукап поле. Наткнулся на невозможность отфильтровать запись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2017, 13:22:10 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_LSV+500. Я делаю обычные поляЗадача: в ячейку грида воткнуть комбобокс с предопределенным выпадающим списком. Раньше это было сделано через позиционирование лукапкомбобокса на ячейку грида. Думал убрать комбобокс и сделать лукап поле. Наткнулся на невозможность отфильтровать записьИменно поэтому я сделал у себя обычное поле. Потому-то решить проблему фильтрации лукапа практически невозможно. У обычного поля к конце кнопочка вызова лукап-формы. Чуть менее удобно, чем комбо, но зато имеет много преимуществ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2017, 16:38:29 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_Задача: в ячейку грида воткнуть комбобокс с предопределенным выпадающим списком. Для этого не нужно lookup поле, просто забей свой предопределённый список значений Grid-y в TColumn.PickList. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2017, 17:03:33 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_LSV+500. Я делаю обычные поляЗадача: в ячейку грида воткнуть комбобокс с предопределенным выпадающим списком. Раньше это было сделано через позиционирование лукапкомбобокса на ячейку грида. Думал убрать комбобокс и сделать лукап поле. Наткнулся на невозможность отфильтровать запись Я когда-то возился с сей "проблемой", решил заменой отказом лукап-полей в режиме отображения на лукап поля в режиме редактирования. Каждый датасет готовлю специально (я использовал комбинацию из особого фрейма с гридом и датасетом, несущественно). Предположим, отображаю список товаров Goods, показываю наименование товара и наименование типа товара из таблики KindOfGoods: Код: sql 1. 2. Все отлично "фильтруется и сортируется". Нужно как-то редактировать поле kg_name. К описанию добавляю список (в данном случае из одного элемента) псевдо-лукап полей: Код: pascal 1. И для этого поля указываю все необходимые данные для реализации его "редактирования": Код: pascal 1. 2. 3. 4. Все, все необходимые данные для создания лукап-комбобокса есть. В момент редактирования в ячейке грида создается контрол (использовал из набора EhKib), инициализируется и отображается. После завершения редактирования выполняется апдейт поля kg_id текущей записи таблички Goods, контрол редактирования уничтожается, выполняется Refresh текущей записи грида. Всё. Я уже не помню подробностей, но идея, надеюсь, ясна. Реальной работы ничуть не больше, чем при возне с настоящими лукап-полями, зато и преимущества налицо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2017, 17:47:26 |
|
||
|
filter+lookup вместе живут?
|
|||
|---|---|---|---|
|
#18+
В общем, для потомков. dblcbBuilds - TDBLookupComboBox, dbgAssemblyList - TDBGrid Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2017, 15:12:40 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=37830984&tid=2041722]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
170ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 501ms |

| 0 / 0 |
