31.10.2007, 06:18 | #1 |
Участник
|
Есть поле, на которое я накладываю фильтр. Надо отсеять дубликаты в этом поле в результирующем НД. Аналог DISTINCT в запросах. Подскажите, можно ли так сделать, или придется все значения выбирать (и получать) и разбиратся с ними уже на клиенте?
|
|
31.10.2007, 12:45 | #2 |
Участник
|
Можно сделать в SQL View с distinct и связать его с таблицей в навижн (LinkedObject).
Либо сделать хранимую процедуру с distinct и вызывать её из навижн. В любой случае, на стороне клиента это к сожалению решить нельзя. |
|
31.10.2007, 12:59 | #3 |
Участник
|
Цитата:
Рек.FIND('-'); Рек.SETRANGE(Поле, Рек.Поле); Рек.FIND('+') Рек.SETRANGE(Поле); Рек.NEXT(); Рек.SETRANGE(Поле, Рек.Поле); Рек.FIND('+') ну и тд ... То есть получив стопку записей с одинаковым значением вашего Поля фильтровать по значению, переходить на последнюю запись, снимать фильтр и выполнять NEXT для получения нового значения Поля.... Оформить все это в цикле. |
|
31.10.2007, 14:10 | #4 |
Участник
|
Этот метод слишком не производителен.
Особенно если обрабатывать большие таблицы, лучше от него отказаться сразу, если есть такая возможность. |
|
01.11.2007, 04:51 | #5 |
Участник
|
Я в таких случаях закидываю отсортированные данные во временную таблицу, что-то вроде:
IF Source.FINDSET THE REPEAT IF нет еще такой записи THEN BEGIN TargetTmp := Source; TargetTmp.INSERT; END; UNTIL Source.NEXT = 0; И потом уже работаю с этой временной таблицей. Я заметил, что временные таблицы в Наве можно частенько юзать как некий аналог запросов. |
|
01.11.2007, 09:12 | #6 |
Участник
|
Цитата:
А так вполне хороший метод обеспечивающий достаточную производительность даже на ОЧЕНЬ БОЛЬШИХ таблицах. Все таки для каждой задачи есть свои инструменты , имхо забивать гвоздики кувалдой не стоит. Вьюхи дело конечно хорошее, НО имеются свои недостатки: 1. Теряется мультифирменность (можно избежать соединив все таблицы через UNION ALL, но слишком дорого выходит поддержка такого решения) 2. Само собой не будет работать на Native DB. 3. Усложняется обновление боевых баз. |
|
01.11.2007, 12:12 | #7 |
Участник
|
Наблюдается ОЧЕНЬ сильное замедление работы с временной таблицей, когда число записей в ней находится в районе или превышает 10000 записей. Это на заметку. Ну и структура (число полей и размерность) имеет значение.
|
|
01.11.2007, 13:32 | #8 |
Участник
|
|
|
02.11.2007, 04:00 | #9 |
Участник
|
Цитата:
К тому же, для временной таблицы можно созать свой табличный объект с теми только полями и ключами, которые необходимы в данном случае. Тогда вообще можно просто (если из полей сортировки исх. таблицы создать первичный ключ для временной): TargetTmp := Source; IF TargetTmp.INSERT THEN; Собственно, именно такой вариант я и рассматриваю как некий навовский эквивалент запросам. |
|