Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Дед Пахом писал(а):Насколько помню, {prop:SqlFilter} начинает путать таблицы. Вроде бы это лечилось ключом /JOINTYPE, но осадок остался.
Опять же, не столкнулся. Вот с prop{SQLOrder} были проблемы, пришлось отказаться.
Yufil писал(а):Предпочитаю данные подкачивать по SetQueueRecord,
На слабом канале очень сильно тормозит. Если всё запихать в один запрос, быстрее гораздо. Ещё используем (правда, мало-мало) после формирования очереди в ResetQueue запустить что-нибудь сильно сложное и раскидать результаты в существующую очередь.
Ну, я там ещё кэшировал поля кодификаторов. И хотфилды, отображающиеся за пределами Browse убрал из таблицы, а подгружал по мере...
В общем, полететь не полетело, но ползать стало шустрее...
PavelNK писал(а): Все гораздо проще и лучше. Работайте через ADO, чрезвычайно удобно и быстро.
А какой ADO используется в С10, ADO или ADO.NET? Хотя бы основные преимущества ADO в отличии от ODBC(в моем случае mysql)
в Clarion, без фанатизма , на Ваш взгляд?
kreator писал(а): Для примера, броуз по нескольким таблицам.
И это ещё не все нужные таблицы. Некоторые значения из не подвязанных таблиц вытаскиваются через подзапросы.
А как обстоят дела с алиес, у меня используется несколько раз один и тот же справочник, например валюты?
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
RaFaeL писал(а):Т.е. если у вас в справочнике допустим 10000 контрагентов то грузите сразу 10000? И не тормозит?
В любом случае нужно думать головой прежде чем отображать всех. Но 10000 не тормозит, незаметно даже. Есть у нас таблица ~130000 записей. Вот это дело вываливается секунд за 4-5. Это да. Но тут ещё пересылка по сети таких объёмов даёт знать. И хочу отметить Firebird, который очень странно кэширует данные. Нет у него опции "засунь всё в оперативку". И, надо заметить, что при таких списках есть проблема у контрола List, в частности неправильно работает ползунок.
интересно,зачем вываливать столько записей? может просто результат обработанный на сервере?
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
gopstop2007 писал(а): PavelNK писал(а):
Источник цитаты Все гораздо проще и лучше. Работайте через ADO, чрезвычайно удобно и быстро.
А какой ADO используется в С10, ADO или ADO.NET? Хотя бы основные преимущества ADO в отличии от ODBC(в моем случае mysql)
в Clarion, без фанатизма , на Ваш взгляд?
Тот, который установлен в используемой ОС. Разницы между ADO и ADO.NET - нет. NET это просто обертка.
Если говорить глобально, то ADO более новый стандарт (вариант ODBC). В ODBC в принципе все есть, но я имел ввиду принцип работы Клариона с БД, исключительно с помощью файлов. Так вот, с помощью ADO можно уйти от этого, т.е. от файлов. Работать гораздо проще, удобнее и нет дополнительной прослойки.
gopstop2007 писал(а):А как обстоят дела с алиес, у меня используется несколько раз один и тот же справочник, например валюты?
Вот привёл картинку. Таблицы на "A" - все Алиасы.
gopstop2007 писал(а):интересно,зачем вываливать столько записей? может просто результат обработанный на сервере?
Просто это справочник. Конечно, потом пользователь ищет по первым буквам, по входимости и т.д. Естественно, нереально всё это просматривать. Но время загрузки получилось небезобразное, ну и ладно. Вообще отдельная история - что делать с большими справочниками.
kreator писал(а):То же самое. В чём тормоза? Мы делаем загрузку (Loading Method) типа "File". Все встроенные подзапросы стараемся пихать через вкладку "SQL Advanced". Единственное, согласен, идёт вызов методов и, кажется, не единственный раз (по логике не понятно зачем). Но несколько раз данные по сети не гоняет (Есть такое мнение у народа). Опять же, может быть, потому что десятка.
В browse две реляционный связанные таблицы (накладная+детали накладной), связывать стандартно через реляцию или через "SQL Advanced"? Еще, просто открыл окно со созданым списком (mdi окно, метод загрузки - page), оставил на 10 минут, после чего хотел закрыть окно и получил ошибку
gopstop2007 писал(а): оставил на 10 минут, после чего хотел закрыть окно и получил ошибку
Стандартная вещь для MySQL - сервер разрывает неактивное соединение. Можно в конфигурации сервера прописать время (по умолчанию кажется минут 10), можно постоянно посылать серверу запрос (т.н. KeepAlive), чтобы он не рвал соединение.
Да, все правильно, ДП!!!
Я ещё вешаю на экран обычный таймер, чтобы идентифицировать окна, из которых идёт пинг к базе.
Типа: это окно можешь держать долго открытым!)
10 минут по умолчанию - это круто . Помню, в SQLAnywhere я выставлял такой же параметр на 8 часов. Пользователь пришёл с утра, включился и до вечера. А FB, похоже, вообще не заморачивается на эту тему.
Дед Пахом писал(а):Стандартная вещь для MySQL - сервер разрывает неактивное соединение. Можно в конфигурации сервера прописать время (по умолчанию кажется минут 10), можно постоянно посылать серверу запрос (т.н. KeepAlive), чтобы он не рвал соединение.
Извините за дилетантские вопросы, но так как я работал на MAV ODBC, есть ли аналог
kreator писал(а): 10 минут по умолчанию - это круто . Помню, в SQLAnywhere я выставлял такой же параметр на 8 часов. Пользователь пришёл с утра, включился и до вечера. А FB, похоже, вообще не заморачивается на эту тему.
согласен, если сервер локальный
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
Алексей- Софт-Центр писал(а): Да, все правильно, ДП!!!
Я ещё вешаю на экран обычный таймер, чтобы идентифицировать окна, из которых идёт пинг к базе.
Типа: это окно можешь держать долго открытым!)
Алексей
По моему это через чур, ладно если окно форма, а так окно browse выполнило запрос и работаем с результатом, не понятно зачем забивать сеть пингом, ладно если сервер локальный, а если сервер на внешнем хостинге не сильно и "пинганешь"
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп