Код: Выделить всё
/BINDCOLORDER=2 /BUSYHANDLING=2 /JOINTYPE=DB2 /VERIFYVIASELECT=TRUE
Модератор: Дед Пахом
Код: Выделить всё
/BINDCOLORDER=2 /BUSYHANDLING=2 /JOINTYPE=DB2 /VERIFYVIASELECT=TRUE
Мы запросы обрабатываем так. Создали в БД файл с одним полем типа Varchar (говорю о Firebird), в dct прописали этот файл, но уже 100 полей. И в программе к нему делаем prop:SQL. Чтобы каждый раз вьюхи кларионовские не строить. А что ещё нового ждать от SV?gopstop2007 писал(а):Появилось ли в С10, что то новое кроме известного sqlfile{PROP:SQL} с предварительно созданным в dct, для работы с запросами для Mysql через ODBC?
мда, зря изголялся А как Join справочники с накладными (связь один*много) выводите в таблице, реляция между таблицами(отношения) в dct как для TPS создаете? У меня в Mysql INNODB используется.
не большое отличие от sqlfile{PROP:SQL}
Спасибо Yufil, попробую.
А что не так? Clarion абсолютно правильно создаёт запросы по связям в словаре. Если нужна оперативная работа с таблицами, то достаточно связей в словаре, шаблоны, классы всё сделают как надо. А sqlfile{PROP:SQL} мы используем для каких-то аналитических запросов. Мы работаем с Firebird'ом, а он своеобразен. И, чтобы получить приемлемый результат по скорости, приходится изгаляться через "select from select" или использовать Derived Tables. В общем, в обычный броуз по-простому конструкцию не загнать.gopstop2007 писал(а):мда, зря изголялся А как Join справочники с накладными (связь один*много) выводите в таблице, реляция между таблицами(отношения) в dct как для TPS создаете? У меня в Mysql INNODB используется.
А что глючит? Не нарывался. Сижу плотно на десятке.Дед Пахом писал(а):На самом деле с JOIN иногда глючит, если в VIEW описано 3 таблицы и больше.
То же самое. В чём тормоза? Мы делаем загрузку (Loading Method) типа "File". Все встроенные подзапросы стараемся пихать через вкладку "SQL Advanced". Единственное, согласен, идёт вызов методов и, кажется, не единственный раз (по логике не понятно зачем). Но несколько раз данные по сети не гоняет (Есть такое мнение у народа). Опять же, может быть, потому что десятка.Дед Пахом писал(а):Мы для более-менее сложных случаев отказались от стандартных Browse - и из-за этого, и тормозные они.
Т.е. если у вас в справочнике допустим 10000 контрагентов то грузите сразу 10000? И не тормозит?
В любом случае нужно думать головой прежде чем отображать всех. Но 10000 не тормозит, незаметно даже. Есть у нас таблица ~130000 записей. Вот это дело вываливается секунд за 4-5. Это да. Но тут ещё пересылка по сети таких объёмов даёт знать. И хочу отметить Firebird, который очень странно кэширует данные. Нет у него опции "засунь всё в оперативку". И, надо заметить, что при таких списках есть проблема у контрола List, в частности неправильно работает ползунок.RaFaeL писал(а):Т.е. если у вас в справочнике допустим 10000 контрагентов то грузите сразу 10000? И не тормозит?
Насколько помню, {prop:SqlFilter} начинает путать таблицы. Вроде бы это лечилось ключом /JOINTYPE, но осадок остался. Так что отказались от VIEW ещё в 8-ке, теперь практически всё в связке DynaDrv+EasyListView.