Выделенные записи на форме в отчёт/форму

[ZVV]

Цитата:

Сообщение от Kopylov

Вторая форма также состоит из 3х датасорсов: SalesTable, SalesLine, InventDim.
Форма самописная, дизайном отличается от формы заказов. На ней так же должны быть возможны манипуляции со строками заказов

Забавно, а что они не могут выбрать эти записи сразу на второй форме?

Если нет, то может вам их стоит рассмотреть вариант просто как-то помечать в стандартной форме (поле например завести какое-то с номером текущей сессии, есть много разных вариантов), а потом открывать во "второй" форме уже помеченные_нужным_образом записи.
Не скажу, что это очень красиво, но возможно вам понравится.

[DSPIC]

2 ZVV: можно взглянуть на код?
Проверил сам - получилось не более 476 критериев.
+ Проверил, тема обсуждалась (Поиск на форуме по "476" или "477")
+ см. вложение

[ZVV]

Цитата:

Сообщение от DSPIC

2 ZVV: можно взглянуть на код?
Проверил сам - получилось не более 476 критериев.
+ Проверил, тема обсуждалась (Поиск на форуме по "476" или "477")
+ см. вложение

Я проверял вот это:

Цитата:

Сообщение от DSPIC

Может прозвучит нелогично, но помнится, когда я с этим экспериментировал, получалось ограничение именно на количество рэнджей, а не на длину в 250 символов. При этом было не важно, сколько самих рэнджей на одно поле наложить:
(2x125 или 1x250) - если в сумме получалась магическая цифра немногим больше 250 то запрос не проходил...

Это не верно, можно это проверить без всякого кода, сформировав в фильтре ручками пару-тройку рэнджей на одно поле, длиной по 250 символов каждый и убедиться что он работает. Проверив уходящий запрос на сторону БД, естественно.

А обсуждаемая магическая цифра 476 (например тут соединить query и временную таблицу) - это уже ограничение несколько другого рода. И не на кол-во ренджей, как могло бы показаться, а на размер SQL-оператора, насколько я понимаю.
Очевидно, ваш пример проверялся на сиквеле, где, помнится размер оператора максимальный 32К (могу ошибаться)? Ну вот оно где-то так и выходит, по моим прикидкам.
На оракле это ограничение выше - 64К (для 9-ой версии, например). (Причём из документации по 10-ке и 11-ке данное ограничение вообще исчезло почему-то) Соответсвенно данный пример может отрабатывать с гораздо большим значением
У меня например успешно отрабатывает такой джоб на оракле:

static void Job_QueryRangeLimit(Args _args)
{
    Query       query;
    QueryRun    queryRun;

    QueryBuildDataSource    qbds;
    QueryBuildRange         qbr;

    int         nextI;
    ;

    query = new Query();

    qbds = query.addDataSource(tablenum(InventTable));

    for (nextI = 1; nextI <= 1200 ; nextI++)
    {
        qbr = qbds.addRange(fieldNum(InventTable, ItemId));
        qbr.value(queryValue(int2str(nextI)));
    }


    queryRun = new QueryRun(query);
    queryRun.next();
}

при дальнейшем увеличении этого кол-ва начинает падать соединение Аксапта с Ораклом

Цитата:

ORA-00600: internal error code, arguments: [733], [36332372], [pga heap], [], [], [], [], []

Точную цифру падения не искал, т.к. не интересно, не очень важно, лень и к тому же она может варьировать в зависимости от некоторых факторов.

Кстати, даже в этом случае (1200), размер SQL-оператора уходящего в БД превышает задекларированные 64к, но работает.

Тестировал на 3.0сп3кр3 + Оракл 9208Вин