Ермаков МихаилheleoВерсия 6.0.17.15 не собирается драйвер Qt под Qt 4 и МСВС 5, ругается на опцию компиляции, удаляем - собирается. А еще, решение с экспортом пути к директории Qt 4 в переменную QTDIR не самая лучшая идея для выбора версии Qt под которую собирается драйвер. Лучше идти стандартным путём qmake, qmake-qt4.

Проверили поведение.

1. qmake работает. Он создает отдельный Makefile. Потом достаточно запустить make -f Makefile
2. В нашей штатной сборке действительно есть один ключ от более нового компилятора. Его нужно убрать там где компилятор не поддерживает - как Вы, собственно, и сделали.

ключ -fno-strict-overflow

qmake - утилита для сборки приложения с использованием Qt 3 либо Qt4 в зависимости от того откуда она вызвана. Как правило выбор производится запуском скрипта для Qt 4 - qmake4 (qmake-qt4), либо прямого вызова qmake для Qt 3. У Вас в документации даже написано (readme.txt файл в паке с исходниками драйвера) "Before compile ensure, that QTDIR and QMAKE enviroment variables are set property.". Это вообще такой маленький грязный хак, что бы собралось с нужной версией. Хотя переменная QTDIR относится чисто к Qt 3, и в Qt 4 не применяется. К тому же у Вас уже создан makefile. После выполнения make он преобразуется в Makefile (с учетом qmake linter.pro и параметров makefile) который собственно и выполняется при компиляции. Если я попробую сходу запустить qmake linter.pro, а потом make -f Makefile, то результатом будет ошибка:


Ошибка кроется во включении необходимых параметров компиляции (include ../Definition, QTDIR) которые есть только в makefile, но не в linter.pro где этим вещам самое место.

Причем в прошлый раз (версия 6.0.15.3х) это использование qmake4 уже правилось. А в 6.0.17.15 вернулось обратно.
И моя самая любимая фича при сборке: Если кто то грохнет по незнанию ваш makefile присутствующий по умолчанию в драйвере, то уже ни как не собрать драйвер. Дальше начинается поиск дистрибутива СУБД или копии этой папки.

Вася Уткин,

Вася УткинЕрмаков Михаилпропущено...

Мы же не pg и не синхронизируемся с их репозиторием никак :).
А по разработчикам - они смогут самостоятельно поддерживать всю систему после потери доступа в помощи открытого сообщества? <оставим в стороне как это будет сделано технически :) >
Если интересуют какие-то фичи, то пишите - будем смотреть - когда и как реализовать. Если ваша компания сможет заказать доработку - можем выполнить заказ :).
Т.е. один раз Линтер-ВС 6.0 отпочковались от PostgreSQL 7.2 и забыли про PG, дальше исключительно своим путем?
Наша фирма продает железо на котором бывает крутиться ваша СУБД. А клиентам зачастую проще, быстрее и дешевле использовать СУБД с готовыми фичами, чем заказывать их :)

Линтер-ВС 6.0.1 живет своей жизнью и дальше, его часто приписывают к Линтер, но делает его другая контора которая собственно запилила МСВС - ВНИИНС. В частности была Линтер-ВС с постгрессом 7.2 и 8.х, и вроде проскакивала новая версия с 9.х, но в руках не держал.
К тому же, постгрес по умолчанию присутствует в AstraLinux с добавлением механизма мандатных меток и сопрягается с ОС при необходимости. Так же постгрес 9.х имеется еще в одной ОС, но по ней точно не скажу, что и как потому как в руки не попадала, но версия постгреса 9.0 или 9.1.

Ермаков МихаилheleoС примерами могу сказать так. Работать с BLOB не совсем ясно как. В примерах показана запись BLOB одноразовая, а если нужно записать в цикле через UPDATE дана только функция INSERT и REPLACE. С INSERT не сложилось, то ли баг, то ли что то еще. В итоге наращивание BLOB произвел через:

В пакете примеров для CALL интерфейса реализована функция LinterAOBJ (exlib.c). В документации по CALL интерфейсу в разделе о добавлении BLOB цитата - "Команда ABLB предназначена для добавления заданной порции BLOB-данных."
В примерах, к сожалению, приведена только команда AOBJ - хотя работают они одинаково. И последовательное обращение к этой функции обеспечивает последовательную загрузку данных в BLOB.
Кстати, а через какой интерфейс Вы пробовали работать?


Работаю я через Qt драйвер, а разговор шел непосредственно про SQL по работе с BLOB.

Ермаков МихаилheleoДальше идем на сторону клиента, где каждому клиенту приходится настраивать файл nodetab с параметрами сервака. Стоит только добавить новую базу или сменить порт и прогулка по всем клиентам обеспечена. К тому же просто поставить nodetab на клиента нельзя, поскольку он не отделен от пакета установки СУБД, а хотелось бы видеть отдельно, и что бы не скриптами это все регулировалось, а полноценным демоном. Так как разбираться где каждый "буратино" хранит скрипты от запуска своей базы и в каком месте при старте ОС он их вызывает очень не хочется.

Зависит от поставленной задачи. Интересно, а как будет в случае смены порта или инстанса в oracle? Не придётся перенастраивать клиентские?
Вариантов решения много - от размещения на неком разделяемом ресурсе общего файла до интеграции наших клиентских компонент в свой приложение (опять же для работы клиента нужно только 2 файла и никаких скриптов кроме запуска).

Тут нужно понимать две вещи:
1. Файл этот будет настраивать админ.
2. Выбор базы настроит пользователь в ПО сам, один раз и тогда когда надо будет, но без пункта 1 в Вашем случае к СУБД не подключиться никак.

В чем и кроется плюс постгреса - настраивается только ПО, причем для этого не обязательно нужен админский доступ, хватит реквизитов хоста\имени базы у пользователя на бумажке.

Ермаков МихаилheleoНаличие скриптов создания системных таблиц базы которые надо затянуть вручную при создании своей базы. Нельзя внутрь спрятать сей момент? Я понимаю, что там можно отключить лишнее и не тащить, но выигрыша от этого я не заметил.
Я не знаю Вашей технологии развёртывания приложения, но согласитесь, это не сложно сделать. Кроме того, потребности у разных систем разные и, бывает, отключение полезно.
Кроме того, если Вы возьмёте почти :) любую систему, то получите что-то подобное - или развёртывание готовой БД с грудой мусора или создание БД с нуля с указанием конкретных параметров.
В нашем случае Вам ничто не мешает получить копию DEMO базы и тиражировать её изменяя параметры по необходимости. Да, для этого в UNIX пока не очень удобные средства, но это тоже временно (см. выше.)

Очень просто, для постгресса мы просто выполняем:


и радуемся развернутой базе. При этом не нужно беспокоится о системных кусках СУБД, для нас и админов этот момент полностью прозрачен. К тому же не нужно думать о тех же LINTER_MBX. Какие бы базы не стояли уже, мы с ними кроме как по имени не будем конфликтовать, а уникальное имя БД не проблема.

Ермаков МихаилheleoСопряжение пользователей СУБД и пользователей ОС нет.

В настоящий момент полностью работоспособна аутентификация через PAM и, локально, через систему.
http://www.linter.ru/documentation.php?ID=3057 - "создание пользователя".
Соответствующая информация должна будет быть добавлена в "архитектуру", но пока обновлённый документ не опубликован.

Хорошо. А возможности аутентификации по trust, ident? Меня вот ident интересует очень.

Ермаков МихаилheleoСопряжение меток ОС с СУБД нет.
Да, нет. Но это дискуссионный вопрос - что лучше. Что проще - понятно. А вот что лучше ....


Ермаков МихаилНу раз далее был разговор про безопасность... Как говорить про безопасность если её настройка лежит полностью на ПО? Получается что запустив inl я сам могу указать метку текущей сессии и под 0й меткой работать с 3й меткой безопасности?

heleoБэкап. Удалось сделать только полный.
А почему не получилось частичный?

heleoОтключение триггеров нет, данный момент реализуется только путем наложения\создания всех проверок (уникальность, зависимоти, включение триггеров) после восстановления таблиц с данными.
Есть. http://www.linter.ru/documentation.php?ID=3057 раздел "состояние триггера"


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

Ермаков МихаилheleoПри восстановлении мне как таковой "ALTER SEQUENCE START WITH X" не подходит. Хотелось бы именно задание значения как в постгрессе pg_catalog.setval('seq', 123, true);
А в чём криминал первой конструкции?

Представьте, что сиквенс от 1 до 100 с автоповтором, то есть некий диапазон допустимых к выдаче значений. И мне нужно сделать дамп а потом развернуть. Для восстановления сиквенса я использую


потому как максимальное предыдущее значение было 98. Вопрос: что будет после перехода через значение 100? В доках постгресса к примеру написано
Можно конечно использовать RESTART WITH или INC, но я не уверен, что это хороший подход при восстановлении дампа. По факту со стартом мы меняем сиквенс а не восстанавливаем его.

Ермаков МихаилheleoОпять же в сравнении с постгрессом, очень не хватает нотисов и особенно именованных констрейнов. К примеру если в коде несколько уникальных ключей, чеков, внешних ключей - выковыривать это не получится. Опять же, если делать обработку в каждой процедуре это просто ад.
нотисы - это комментарии? Если так, то сейчас они уже есть.
http://www.linter.ru/documentation.php?ID=3057 - "создание комментария".


Нет не то. Это по факту фича , не знаю как у остальных СУБД, но очень удобная при наличии тяжелой бизнес логики в процедурном языке.

Ермаков МихаилheleoПроцедуры нужно запускать с указанием имени схемы в которой она создана. При этом для представлений и таблиц еще можно сделать синоним и скрыть этот момент, но не с процедурами. Фактически не хватает схемы паблик.
Да, в настоящее время синонимов на процедуры нет. А вот схема такая недопустима по соображениям безопасности :).

А теперь самый цимус. Чем public Вам не угодил? Все постгрессы которые были у меня в руках имели public и не имели проблем с безопасностью. При этом все шикарно работало, мандатные метки на строки, столбцы, таблицы, доступ к процедурам. Всё это работало как под метками так и с возможностью их обхода при необходимости.

Ермаков Михаил Администратор (если это выделенное лицо) настроит возможность доступа ко всем базам. Эти базы пользователь создать на удалённой машине никак не может. А уж к какому алиасу коннектиться - это он и сам решит. При этом никто не мешает запустить (dbc_tcp) самоcтоятельно и настраивать себе как угодно. Действия лишние понадобятся, конечно, в любом случае.


Вот только не стоит рассчитывать на то, что пользователь будет запускать самостоятельно dbc_tcp, не факт что ему дадут права на это (по факту и не дают). Тогда уж сразу возникает вопрос о безопасности работы с nodetab. Вдруг я захочу его подредактировать, а коллеги то и не заметят, что база не совсем та.

Ермаков Михаил Понятно. В случае необходимости перечисления объектов для backup проблема некоторая есть. Потенциально она решается параметрами. lhbx это позволяет сделать, но сгенерить параметры для backup нет возможности. Вопрос понятен - учтём.
А зачем отключение триггеров? Или Вы хотите использовать backup только для данных в схеме, но не для самой схемы? Т.е. сохранить данные из таблиц и необходимые параметры (те же Sequences). Затем, в аварийном случае, почистить все таблицы и залить их данные из backup? Описана ли эта модель где-то? Мы можем её рассмотреть и сделать в будущем средства для подобных моделей.
Если это так, то становится понятна заинтересованность в установке значения последовательности в конкретное значение :). Учтём.

Да, только не всегда с зачисткой схем. Про модель ничего не скажу, так как у меня это в основном возникатет при сопровождении и разработке. Зачастую, бывает необходимо делать бэкап данных (только части или всех) для переноса на другой сервер, или при разработке есть необходимость внесения корректировки в БД при которой БД можно только пересоздать. При этом нужно сохранить часть данных и восстановить на новую схему. Вот тогда и появляется необходимость отключения триггеров.

Ермаков МихаилheleoНет не то. Это по факту фича , не знаю как у остальных СУБД, но очень удобная при наличии тяжелой бизнес логики в процедурном языке.
Понятно.
http://www.linter.ru/documentation.php?ID=2200 - раздел - генерация пользовательского исключения. Наверное, речь об этом.


Практически об этом, но:
1. У постгреса можно выкидывать не только исключения, но и передавать сообщения из БД без остановки выполнения.
2. Возможность передавать не формализованные сообщения. В вашем случае идет привязка к определенному коду и на выходе будет именно этот код. В итоге приходится лезть в таблицу за определением этого кода, так как просто выдать цифру для нас недопустимо. В постгресе на выход можно отправить текст по любому формату с любым содержанием. В Вашем случае только имеющийся код даже если это пользовательский вид исключения. Причем у Вас только исключения, тех же DEBUG, LOG, INFO, NOTICE, WARNING не хватает особенно при отладке (про дебагер знаем).
3. У Вас может возникнуть один и тот же вид исключения вызванный разными ситуациями, к примеру: два внешних ключа, оба должны быть не NULL, один из ключей пишут NULL или не существующий. Какой именно ключ выкинул исключение не ясно.

Ермаков Михаил А как это "с возможностью их обхода при необходимости" ? :)

К примеру, для функция это параметр при создании (опять же сравнивая с постгресом):

Ермаков Михаилheleo Вот только не стоит рассчитывать на то, что пользователь будет запускать самостоятельно dbc_tcp, не факт что ему дадут права на это (по факту и не дают). Тогда уж сразу возникает вопрос о безопасности работы с nodetab. Вдруг я захочу его подредактировать, а коллеги то и не заметят, что база не совсем та.
Верно. Но есть 2 момента.
1. Как администратор узнает - к какой БД обращается приложение? Т.е. как раз в PG у администратора пропадает возможность контроля за действиями приложения.
2. dbc может быть несколько и каждое приложение может использовать свой nodetab :) - совершенно не обязательно делать его общий.


Получается что контроль над приложением по доступу к БД есть, но управлять nodetab может кто угодно, либо администратор бегает и настраивает каждый ПК да еще под каждое приложение. При этом ни какой централизации управления доступом с различных хостов на сервере нет. Получается что nodetab будет выполнять свои функции нормально до тех пор пока в сети все ПК под жестким контролем админа и их количество не превышает некоего критичного порога обслуживания. А если ПК работает удаленно или все ПК без администрирования... Тогда "кто в лес кто по дрова", к томуже пользователь еще должен знать как настроить nodetab и как его запустить.

Ермаков Михаил В нашем случае это может быть стандартный запрос на получение ошибки - GETE из БД по коду. В этом случае Вы получите текстовое описание ошибки из таблиц ERRORS.


По факту так и сделано.
Хотя возникает вопрос: сработает ли данный запрос в блоке begin - commit, если произойдет ошибка, но rollback или commit не будут вызваны до GET?