Да ладно, стандартная реализация на Дельфи такая же тормозная.
С какого такого боку? Понятно что медленнее прямого доступа (вдобавок
учитывающего особенности конкретного сервера), но до тормозов клаши ой как
далеко.
А вот какие сложности в Кларионе я не понял. Драйвер в файлах поменял и в путь.
все работает, не быстро но работает.
Так в том и дело, что так как работает мало кого устроит. А если хочешь
быстрее то слишком много усилий приходится прикладывать.
P.S.
Да и это я так ... по доброте душевной. В тупик клаша зашла и очень
давно. Пока не поздно лучше сваливать.
Martin Mader
(Добавление)
Тут и так многие в курсе.
Масла не подливай.
--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone:
+380 572 177977
WEB:
http://enigmasoft.com.ua
e-mail:
clalist@enigmasoft.com.ua
ICQ:
12253836
Так на Кларионе и быстрее разработали,
и по скорости доступа обогнал все остальные.
Ага это из разряда баек ... из склепа
)
Особенно насчет "скорости доступа"
)) и это при пользовании одного и того
же API
Martin Mader
(Добавление)
Очень даже возможно. На кларе действительно разрабатывается базовый функционал
мгновенно. Но - лишь базовый. Попытка сделать что-то низкоуровневое - кранты.
ЗЫ. 2Вадим:
у тебя получилось заставить клару понять WM_ENDQUERYSESSION?
--
Best regards,
Maxim Yemelyanov
С какого такого боку? Понятно что медленнее прямого доступа (вдобавок учитывающего особенности конкретного сервера), но до тормозов клаши ой как далеко.
Используй разработки/шаблоны для работы с SQL
Так в том и дело, что так как работает мало кого устроит. А если хочешь
быстрее то слишком много усилий приходится прикладывать.
Читай выше
P.S. Да и это я так ... по доброте душевной. В тупик клаша
зашла и очень
давно. Пока не поздно лучше сваливать.
Скажем так, неудачные программеры собрались нынче у Велосипедистов...
Даже среду без ошибок сделать не могут. Но это еще ничего не говорит в целом
о концепции Клириона
---------------------------
С уважением,
Олег Иванов
(Добавление)
Ага это из разряда баек ... из склепа
)
Особенно насчет "скорости доступа"
)) и это при пользовании
одного и того же API
были бы мы в одном городе, я предложил бы пари:)
а вот буду с оказией в Сочи, покажу как работает програмка на Кларе,
связавшись по инету с БД в Москве и выписав парочку накладных.
Ну если конечно на пиво пригласишь:))
------------------------
С уважением,
Олег Иванов
(Добавление)
А вот какие сложности в Кларионе я не понял. Драйвер в файлах поменял и в путь. все работает, не быстро но работает.
О сложности:
1. Если оставить Аппликацию как есть, те. без применения SQL запросов,
то и драйвер менять не надо.
2. Несколько файлов содержат в полях массивы и эти куски надо
переписывать.
3. Попробуйте в SQL таблице объявить поле с именем group, которые были
в TPS. Не пройдет. Попробуйте объявить ключи в SQL с одним именем в
разных таблицах. Тоже не пройдет. А в задаче (привычка старая)-
key1:u, key2:u и т.д. Меняем все в SQL, затем импорт в словарь, затем
импорт из старой аппликации в новую, а там половина полей, кстати как
поля - элементы массивов, - одни рожки торчат.
4. Конвертация через словарь - и не пытайтесь. Опять руками.
Я думаю, что знающие люди продолжат и дальше. Понимаю, что фактически
все надо переписывать. Просто задавал вопрос именно о том, как
построить и обновлять картинку с помощью запросов типа:
SELECT snum, sname, sity, comm FROM Salespeople;
Кстати, что подтолкнуло: После перевода 1С на SQL большая часть
отчетов стала строится на порядок, а некоторые просто не сравнимы.
Фактически, как через терминал. (Сервер 2xXEON -2,8GHZ /RAM1GB, а
станции - большая часть PII -PIII)
Всем большое спасибо.
--
Best regards,
gorky mailto:
gorky@sv3.net.ua
(Добавление)
1. Если оставить Аппликацию как есть, те. без применения SQL запросов, то и драйвер менять не надо.
Это сложность?:)
2. Несколько файлов содержат в полях массивы и эти куски надо
переписывать.
А Причем здесь Кларион? Массивы везде нужно будет переписывать...
3. Попробуйте в SQL таблице объявить поле с именем group, которые былив TPS. Не пройдет.
[GROUP]
Попробуйте объявить ключи в SQL с одним именем в
разных таблицах. Тоже не пройдет.
с каких пор? делаете индексы с одинаковыми названиями.
А в задаче (привычка старая)-
key1:u, key2:u и т.д.
Ради бога
4. Конвертация через словарь - и не пытайтесь. Опять руками.
Как уже написал, это все лишнее, кроме массивов, но с этой проблемой
столкнуться любые программисты независимо от языка программирования
Я думаю, что знающие люди продолжат и дальше. Понимаю, что фактически все надо переписывать. Просто задавал вопрос именно о том, как построить и обновлять картинку с помощью запросов типа:
SELECT snum, sname, sity, comm FROM Salespeople;
Кларион как раз генерит такие запросы.
Как раз другая есть проблема у Клариона, это использование курсоров сервера,
из за чего бывают тормоза.
Кстати, что подтолкнуло: После перевода 1С на SQL большая часть
отчетов стала строится на порядок, а некоторые просто не сравнимы.
Фактически, как через терминал. (Сервер 2xXEON -2,8GHZ /RAM1GB, а
станции - большая часть PII -PIII)
Отчеты ничего не решают, более того это не заслуга 1С.
А оперативная работа с 1С в крупной компании также невозможна,
посадите хотя бы человек 50 и попросите плотненько поработать с документами,
через 5 минут Вы будете растерзаны...
Это уже проходили и не в одном десятке фирм.
Чисто гепотетически, если бы 1С решило эту проблему,
остальным было бы нечего делать на рынке. Спросите любого,
почему не ставите 1С, ответ будет один и тот же.
Всем большое спасибо.
Да незачто:)
----------------------------
С уважением,
Олег Иванов
(Добавление)
Кстати, что подтолкнуло: После перевода 1С на SQL большая часть
отчетов стала строится на порядок, а некоторые просто не сравнимы.
Да ну
Почему то на их форумах слышно в точности обратное. Пока ручками 1С
мозги не вправить быстро она с SQL не заработает.
P.S.
Исключение - некоторые типы запросов в последних релизах ядра стали пошустрее шевелится.
P.P.S.
Сорри за офтопик
Martin Mader
(Добавление)
2. Несколько файлов содержат в полях массивы и эти куски надо
переписывать.
Вопрос решаемый
Код: Выделить всё
RECORD RECORD
myDim GROUP
Field1 LONG
Field2 LONG
END
FieldDim LONG,DIM(2),OVER(myDim)
END
END
3. Попробуйте в SQL таблице объявить поле с именем group, которые были в TPS. Не пройдет.
Пройдёт
Для этого есть EXTERNAL NAME атрибут у поля
GROUP LONG,NAME('ПриемлемоеИмя') ! а вообще можно ли в качестве имени
GROUP задавать, не проверял
Попробуйте объявить ключи в SQL с одним именем в разных таблицах. Тоже не пройдет.
Пройдёт
В проекте оставляй с одинаковыми как есть, в БД сделай разными. Ключи то при работе с SQL используются для формирования ORDER BY конструкций и связок по JOIN в клашиных View, по именам они не юзаются
И как уже всегда говорил, проектировать БД надо средставми заточенными под эти дела,
Кларион же это инструмент для создания ТОЛЬКО клиентской части.
4. Конвертация через словарь - и не пытайтесь. Опять руками.
Я думаю, что знающие люди продолжат и дальше. Понимаю, что фактически все надо переписывать.
По большому счёту да, но можно перейти и последовательно перерабатывать код в сторону упрощения, как я уже несколько раз говорил, например:
есть задачка - покажи мне родителей + скока таких внучек, у которых дети старше 40 лет, а у тех есть свои дети, причём только девочки, и в кармане у каждой всегда имеется денюжка
достоинством >=$100
На SQL это одна строчка - грамотный SELECT, на TPS самое логичное это
клашина VIEW, но с бОльшим кодом реализации, открыть, закрыть и т д
Все перечисленные вопросы на тему не пойдёт - решаются, и уже реальный
проект, с любой структурой в словаре можно перевсти на SQL, не меняя при
этом APP, далее последовательный процесс оптимизации кода - переработка
одним словом.
Andrew Myalin
Написал: ClaList(2)
:laugh: