Как проще и быстрее начать ваять проги на Clarion-е для использования баз SQL?
в словаре (DCT) у файлов установить соответствующи SQL драйвер.
в OWNER прописать строку соединения
Можно ли (нужно ли, возможно ли, правильно ли) обходится без формирования SQL-запросов в тексте Clarion-овской программы в явном виде, то есть пользоваться привычными SET, PUT, GET, NEXT, RECORD и т.д.?
в том то и дело, что для каждого драйвера внутренняя реализация файловых
функций своя, т е для SQL акселераторов все SET, PUT, GET, NEXT, RECORD в конечном счёте превратятся автоматически в SQL запросы к БД.
Вам не потребуется самому явно писать PROP:SQL команды.
Andrew Myalin
andrew@arsis.ru
http://mavcla.arsis.ru (MAV Direct ODBC)
ICQ:
10659412
Yahoo group:
clarion@yahoogroups.com
(Добавление)
Привет!
Я работаю Clarion+SQL давно (6 лет), и опыт такой:
1. Можно пользоваться и привычными
SET, PUT, GET, NEXT, RECORD и т.д. без вреда для здоровья
2. Но можно довольно часто применять {Prop:SQL}, что выручает в вопросах производительности
3. Чем больше логики на сервере - тем лучше.
4. Главная проблема - SQLщики часто любят менять форматы записей базы, что для клары смерти подобно. Часто приходится вместо синхронизации (которая в кларе глючит по-страшному) применять ручное сравнение таблиц, что задалбливает при больших базах.
5. При неправльно спроектированной базе (на сервере) написать клиента на кларе бывает просто невозможно.
6. Надо быть осторожным в настройках Browse -
- рекомендуется loading method: page
- локатор - filtering
- filter - тут надо быть осторожным, иногда лучше не применять вообще, а доназначать через методы класса BrowseClass или через SQL:PropFilter в рантайме. И обязательно проверять предварительно на Evaluate (даст ошибку или недаст).
- range limit type - ничего кроме relationship (остальное проще руками и также через PropFilter)
(для начала можно и стандартными средствами пользоваться, но потом настоятельно рекомендую от них отойти)
7. При некоторых ошибках при проектировании базы те формы, которые содержат на закладках дочерние таблицы, могут зависать или намертво портить радительскую запись. Поэтому я такие закладки убиваю насмерть, а к дочерним файлам обращаюсь через кнопки на "главном" browse. Лучше конечно базу проектировать правильно, но от всех ошибок на этапе проектирования не избавиться, а юзер часто хочет первый результат побыстрее.
Александр Агеев (
aageev@satren.ru)
Написал: ClaList(2)
