forum.clarionlife.net

kreator писал(а): Всё должно заработать сразу.

ВСЁ сразу не заработает
1) Мы правили ABC-шаблоны чтобы работала автонумерация, иначе не работала в нужном объеме
2) ВСЕ ключи, по которым идут browse должны быть УНИКАЛЬНЫМИ. Иначе двоит последнюю запись до бесконечности. Переделывали считай все таблицы (везде добавить уникальное поле, добавить автонумерацию, добавить уникальное поле в ключи, по которым броузы)
3) 0 и NULL в SQL это разные вещи, если у вас связь по полю и там 0 то запись тупо не добавится с ошибкой. Прописывали триггеры, которые перед добавлением делют setnull если 0
4) Меняли все поля которые STRING на CSTRING - в итоге вроде как можно было не делать, но по какой-то причине делали, уже не вспомню

... (куча разных мелочей)

99) В итоге пришлось отказаться от ABC-броузов и написать свои на DynaLib так как штатные шаблоны уж очень неторопливо работали. В основном это каталось ситуаций, когда в одном окне с десяток броузов сложных
100) PROFIT. Забыли о падении файлов и вообще каких-то проблемах с базой. Единичные случаи касались либо ошибок в программе, либо физического повреждения серверов. Есть клиенты, которые 10 лет работают без проблем, не преувеличение, потом звонят говорят - решили сервер обновить, что как, мы думали они давно уж про наш софт забыли, а вот и нет

Правда, это все касается MSSQL. Может, с другими серверами ситуация другая, не знаю, не пробовали

Минус - приходится держать параллельную tps-версию в качестве демо, там как демка на MS SQL это за гранью добра и зла ))))

kreator писал(а): Про Actian PSQL (Btrieve) не скажу, но лучше тоже подумать прежде.

Безусловно вариант с поддержкой полноценного SQL намного перспективней. Здесь никто спорить не будет.
Но это большой объем работ, который сразу не сделаешь, особенно если нужно поддерживать старое приложение.
Вариант с Btrieve - это, как говорится: "здоровый кот - без всяких хлопот" (если верить рекламе).

Скажем так, насчет перспективности sql сегодня, а тем более в связке с кларионом, пусть каждый сам своей головой думает и решает...

Поскольку речь зашла про tps, то не забываем о варианте с терминальным сервером (стандартный виндовый или tsplus). Переписывать программу не надо, скорость работы на 2 порядка выше по сравнению с файл-шарингом, ничего не ломается. Куча других плюсов. До 50 конкурентных пользователей очень эффективное решение.

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

SQL привнесенная технология, под которую кларион изначально не затачивался. Работает как-то...

finsoftrz писал(а): Поскольку речь зашла про tps, то не забываем о варианте с терминальным сервером (стандартный виндовый или tsplus). Переписывать программу не надо, скорость работы на 2 порядка выше по сравнению с файл-шарингом, ничего не ломается.

Так все как раз и началось с того, что тормозит tps у человека ))

finsoftrz писал(а):Работает как-то...

Вот именно эти слова по моему про TPS

RaFaeL писал(а):

finsoftrz писал(а): Поскольку речь зашла про tps, то не забываем о варианте с терминальным сервером (стандартный виндовый или tsplus). Переписывать программу не надо, скорость работы на 2 порядка выше по сравнению с файл-шарингом, ничего не ломается.

Так все как раз и началось с того, что тормозит tps у человека ))

У него тормозит файл-шаринг. Уйти от файл-шаринга можно несколькими способами. Поднять терминал - самый простой и быстрый, не требующий изменений в приложении. Точнее сказать, изменения могут потребоваться в паре случаев. Первый, когда пользовательские каталоги под временные файлы прописаны под работу на отдельной станции. В терминале их лучше расположить в каталоге программы. Это мелкое изменение. Второй, когда программа интегрируется с какой-то внешней системой, не работающей на терминале. Это достаточно редко.

Admin писал(а):

finsoftrz писал(а):Работает как-то...

Вот именно эти слова по моему про TPS

Мы все все понимаем. Достаточно посмотреть, как работают с sql другие системы, и немного подумать об этом. Жесткая архитектура клариона может быть большим плюсом при одном подходе и большим минусом при другом. В нише учетных систем я хорошо понимаю, какие конкурентные преимущества имеет система, разрабатываемая на кларионе и встроенном формате (tps и первасив конкретно), и не вижу, в чем конкурентное преимущество системы, разрабатываемой на кларионе в связке с sql. Достаточно давно это было. Я тоже под влиянием общего мнения изучал работу клариона с sql. Но потом понял, что надо полностью пересматривать все, и задался вопросом, а что это даст в конце пути. Внятного ответа не нашлось... Я не агитирую кого-то за что-то. Мне это не надо. Я не вижу смысла спорить на эту тему, так как для меня вопрос давно решен и закрыт. Но вбросить в обсуждение альтернативное мнение полезно, кого-то это может стимулировать задуматься и принять в своей ситуации наиболее оптимальное решение...

finsoftrz писал(а): Я тоже под влиянием общего мнения изучал работу клариона с sql. Но потом понял, что надо полностью пересматривать все, и задался вопросом, а что это даст в конце пути.

Это даст разделение приложения и БД. Котлеты отдельно - мухи отдельно.
Под БД на SQL можно писать обработки не связанные с Clarion (те же WEB сервисы) и в перспективе безболезненно
перейти на другую среду разработки. Ну и плюс богатый функционал встроенных операций самого SQL ... Круто !

Игорь Столяров писал(а):

finsoftrz писал(а): Я тоже под влиянием общего мнения изучал работу клариона с sql. Но потом понял, что надо полностью пересматривать все, и задался вопросом, а что это даст в конце пути.

Это даст разделение приложения и БД. Котлеты отдельно - мухи отдельно.

Другая точка зрения. SQL - это программа, содержащая логику обработки данных. Со своими служебными таблицами, полями и внутренними зависимостями. Наше приложение работает не с данными напрямую, а взаимодействует с этой программой. Поэтому мы не имеем четкого разделения приложения на данные и код. При встроенном формате данные отдельно, код отдельно. Мы можем работать с данными как через слой бизнес функций, который генерим шаблонами на основании информации в словаре, а можем и напрямую с таблицами. То есть степень разделения данных и кода зависит от "плоскости" таблиц.

Игорь Столяров писал(а): Под БД на SQL можно писать обработки не связанные с Clarion (те же WEB сервисы) и в

На встроенном формате тоже можно, но несколько иначе. Через сокеты.

Игорь Столяров писал(а): перспективе безболезненно
перейти на другую среду разработки. Ну и плюс богатый функционал встроенных операций самого SQL ... Круто !

Как средство миграции на другую систему разработки да, логично. Вопрос в том, а зачем тогда тратить ресурсы на разработку в связке клариона и sql. Вопрос, видимо, риторический...

Во-первых, топик зас...ли. Он не об этом.

Admin писал(а):Вот именно эти слова по моему про TPS

Во-вторых, +1.
В-третьих (к RaFaeL'ю больше), Вы когда-то столкнулись с проблемами на Кларионе 2.0 или 4.0, и приводите 99 пунктов надуманных проблем. Их давно нет. Драйвера работают очень быстро, особенно прямые. Стандартные ABC-классы давно заточили под SQL. Единственное - уникальные ключи, но опять же - они ведь виртуальные, реально их может не быть. У меня есть пример. Ребята перетащили с tps таблицу в FB, в ней нет ни первичного ключа, ни развитых индексов, некое хранилище на несколько миллионов строк. А что, в tps это работало через ж., и теперь в FB работает также. С постраничным просмотром, с жуткими тормозами при листании страниц или даже при работе колёсиком мыши. При этом всегда сидит вопрос - "А что мы получили при переходе на SQL? Такое же г., только ещё и с гемором в виде сервака". Понимаете, любую хорошую идею можно довести до абсурда.

kreator писал(а): Вы когда-то столкнулись с проблемами на Кларионе 2.0 или 4.0, и приводите 99 пунктов надуманных проблем. Их давно нет. Драйвера работают очень быстро, особенно прямые. Стандартные ABC-классы давно заточили под SQL.

Переходили на 5.5, затем 6.2, 6.3. Описанные проблемы оставались. Могу конечно посмотреть что там в С10, но что-то не уверен. Драйвер сейчас сам делает setnull что ли? Или в шаблоны вставлено? Про скорость - сам драйвер работает адекватно, под SQL не заточен сам принцип ABC-броузов. Когда их в форме 50 штук, она открывается очень долго (в файловой локально вполне адекватно), клиентов это не устраивало, пришлось написать динамические, в которых броуз на форме один, но динамически при переключении между закладками грузим туда нужные данные

finsoftrz писал(а): не вижу, в чем конкурентное преимущество системы, разрабатываемой на кларионе в связке с sql

Вот прям сейчас какие-то ребята делают нашему клиенту какие-то отчеты в Power BI, причем мы узнали уже постфактум, у нас даже структуру базы не спрашивали. Хрена с два у них бы это вышло с tps, скорей сказали бы клиенту. чтобы он систему менял. Второе - для модуля складского учета (все эти остатки, резервы и т.п.) почти всю логику написали на хранимках в SQL, работает оч быстро и удобно, на клиенте только формы. Сделали систему полного внутреннего логирования на триггерах(когда хранится кто что где когда изменил, вплоть до значений конкретных полей, старого и нового), на файловой структуре это все будет заметно, на SQL не заметно вообще (ну если сервер адекватный). И т.д. и т.п.

RaFaeL писал(а):

finsoftrz писал(а): не вижу, в чем конкурентное преимущество системы, разрабатываемой на кларионе в связке с sql

Вот прям сейчас какие-то ребята делают нашему клиенту какие-то отчеты в Power BI, причем мы узнали уже постфактум, у нас даже структуру базы не спрашивали. Хрена с два у них бы это вышло с tps, скорей сказали бы клиенту. чтобы он систему менял.

Есть встраиваемые дизайнеры в кларионовское приложение, на которых можно делать пользовательские отчеты. В целом, да, если разрешено что-то дописывать в обход приложения, sql может быть удобен. Тут надо разделять по целевой аудитории клиентов. У нас пользователи сами ничего не дописывают, если что надо, то заказывают непосредственно у разработчика. Таким образом управление проектом централизуется. Бывают, продвинутые делают что-то сами. Например, формы ценников разных кучку понаделали. Я беру их и передаю всем нуждающимся, согласовав с авторами, конечно.

RaFaeL писал(а): Второе - для модуля складского учета (все эти остатки, резервы и т.п.) почти всю логику написали на хранимках в SQL, работает оч быстро и удобно, на клиенте только формы. Сделали систему полного внутреннего логирования на триггерах(когда хранится кто что где когда изменил, вплоть до значений конкретных полей, старого и нового), на файловой структуре это все будет заметно, на SQL не заметно вообще (ну если сервер адекватный). И т.д. и т.п.

Тоже есть система логирования на tps, подключается автоматом, вручную писать ничего не надо. Только в ручном коде оформлять не напрямую через add/put/delete, а через вызов соответствующих процедур бизнес логики. На скорость работы программы принципиально не влияет, хотя логи растут быстро, примерно 4:1 относительно основной базы данных. Подсчет оперативных остатков тоже ведется полностью автоматически, модификация через вызов функции бизнес логики...

kreator писал(а): Во-первых, топик зас...ли. Он не об этом.

Я стараюсь не "насиловать" людей лишний раз, когда развивается "тема не по теме". Думаю это никому не нужно

Admin писал(а): Думаю это никому не нужно

А не создать ли нам опросик на тему "Использования форматов БД с Clarion" ?
Сразу будет видно, какие предпочтения у разработчиков ...