forum.clarionlife.net

ЗДРЯМ!

Один непростой вопрос, на который хочется получить простой ответ

Как проще и быстрее начать ваять проги на Clarion-е для использования баз SQL?
а именно:

Можно ли (нужно ли, возможно ли, правильно ли) обходится без формирования SQL-запросов в тексте Clarion-овской программы в явном виде, то есть пользоваться привычными SET, PUT, GET, NEXT, RECORD и т.д.?

хочется к тому же обойтись без дополнительных библиотек для доступа к базам данным (вопрос быстродействия для меня сейчас не актуален)

среда: C55EE(H) + ШВС + MSSQLServer2000DE

СПАСИБО

--
Best regards,
Иван mailto:shkmail@inbox.ru
Написал: ClaList(2)

Как проще и быстрее начать ваять проги на 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)

Спасибо за конструктивный совет ))

--
Best regards,
Иван
Написал: ClaList(2)

4. Главная проблема - SQLщики часто любят менять форматы записей базы, что для клары смерти подобно. Часто приходится вместо синхронизации (которая в кларе глючит по-страшному) применять ручное сравнение таблиц, что задалбливает при больших базах.

Как раз столкнулся с такой проблемой - один раз синхронизация прошла удачно, а дальше - ошибка и все....

А если создавать словарь заново и подключать его к имеющемуся приложению?
Только при этом все префиксы таблиц и их имена по новой надо править.

И вопрос по C6:
функции MultiTable Import и Sinchronize Dictionary в Enterprise Edition (как в С5) имеются?
а то я у себя в C6.0 (build 0.915)Professinal Edition их не нашел.
Там синхронизация тоже глючит?

--
Best regards,
Иван

Иван,

Я бы уточнил, что на десктопных базах (TOPSPEED, Clarion, ...) таки да, действительно, малейшее несоответствие формата файлов/таблиц приводит программу в ступор. А сиквел гораздо более терпим к этому делу. Можно добавлять сколько угодно новых полей в таблицу - старая версия клиентской программы будет продолжать безболезненно работать. Лишь бы старые поля по-прежнему присутствовали. Соответствие ключей/индексов - глубоко безразлично. Некоторое несоответствие типов данных тоже переваривается.
Конвертировать таблицу из старого формата в новый нет нужды, сервер это делает походя. Так что не так уж все и грустно. Если сам себе администратор БД и одновременно разработчик клиентской программы, то проблем вообще нет, если сам их себе не создашь.

Создавать словарь заново было бы можно, если бы не было привязки приложения к словарю через внутренние идентификаторы. Если заглянуть в TXD, то там их можно увидеть у каждой таблицы или поля как IDENT(xx). Можно там же их и исправлять у вновь созданного словаря, но без своего "синхронайзера" тогда не обойтись.

Функции MultiTable Import и Sinchronize Dictionary в С6 Enterprise Edition имеются. Насколько глючны, не скажу.

С уважением,
---
Oleg Fomin oleg@fomin.info
http://www.FominTools.com for Clarion developers

Привет, Олег!

В принципе согласен, но слегка поправлю:

1. Поля добавляются как правило для того, чтобы их использовать. Поэтому после добавления новых полей надо залазить в словарь, импортировать таблицу как новую, с дальше пробагаться по ней глазами. Новые поля можно к старой таблице дабавлять без проблем (^c в новой, ^v в старой). Место вставки значения не имеет. А вот изменять поля тем же способом нельзя - оболочка запоминает не названия полей, а их Ident, поэтому удаление _любого_ объекта словаря приведет к пропаданию его из APP.

2. Я C6 пользуюсь ОЧЕНЬ редко, т.к. пишу проги на заказ, и воевать с не-своими глюками не желаю. С SQL там пока ещё не работал.

Александр Агеев (aageev@satren.ru)
Написал: ClaList(2)

По этому поводу хочу поделиться своим скромным опытом.
Конвертанув свои данные из TPS в MSSQL2000, я долго бился над фильтром по дате.
Так вот, заработало ТОЛЬКО тогда, когда я, ничего остального не переделывая в кларионовскийх фильтрах, вместо
SELF.SetFilter('(JOR:Date >= DateStartG and JOR:Date <= DateEndG)
написал скульный кусочек:
BRW1::View:Browse{PROP:SQLFilter}='Date_Z between '''&CLIP(FORMAT(DateStartG,@D6-))&' 00:00:00.000'' and '''&CLIP(FORMAT(DateEndG,@D6-))&' 23:59:59.998'''
По-другому никак не работало.
Всё заработало с подачи В.Синявского, за что ему огромный спасиб!

--
С уважением,
RozAlex
rozalex@pisem.net
ICQ#: 48572306
YM!#: RozAlex2000
IRC : irc.rinet.ru:6669 #Clarion, #1C
Написал: ClaList(2)