AlexeyGВ http://]www.relex.ru/linterdocs/newdoc/ProcLan/2_9_2.htm ... Претранслированные запросы будут реализованы в последующих релизах СУБД ЛИНТЕР.

Это когда?

Сделаны уже. Документация как всегда отстаёт.

AlexeyGЕще вопрос по процедурному языку
Из http://]www.relex.ru/linterdocs/newdoc/ProcLan/2_8_13.htm следует что я не могу написать что-то типа (PL/SQL)

Процедура выглядит так:
procedure ...
declare
блок переменных
code
тело процедуры
exceptions
обработка исключений
end;

Динамически формируемые запросы выполняются execute direct "...". Есть также претранслируемые запросы (без direct).

VARCHAR есть. Конструкция типа table.field%type тоже есть. Выглядит так:
var ... typeof(schema.table.column);

В ЛИНТЕР процедур изначально не было вообще. Поэтому они сделаны отдельно от SQL. Отдельный язык, отдельный транслятор, отдельная исполняющая подсистема. IMHO из нашего сиснтаксиса это видно. Такая связка не рассчитана на серьёзные нагрузки. При большом количестве процедур со сложной логикой сервер захлебнётся...

Локшин МаркНе правда, несколько на сказку похоже?
Про enterprise несколько прояснили, но все равно, и на рынке небольших БД и Oracle и MS и Sybase смотрятся предпочтетельней, у них к примеру нормальные хранимые процедуры есть :)
:-) Предпочтительней для чего? Вот например, есть Oracle, MS или Sybase под QNX? Sybase был :-(
А ЛИНТЕР есть. Есть примеры когда очень известные мировые компании выбирали из многих СУБД и выбирали ЛИНТЕР. Не хочется вдавться в полемику, но несмотря на определённые недостатки ЛИНТЕР имеет и свои достоинства, и некоторые возможности, которые не может предоставить ни одна другая СУБД. Хотя бы уникальная система разграничения доступа и защиты от НСД, или в строенная в ядро подсистема полнотекстового поиска...
А ссылку/аннотацию не дадите?
Ой даже не знаю... Году в 98-ом Лиля Козленко выступала на московской секции SIGMOD. Что-то про иерархические транзакции кажется.

AlexeyGИнтересно узнать о далеком будущем Линтер, есть ли у вас планы реализовать процедуры более эффективно?
Да, сейчас ведётся очень серьёзная работа. И вспоминая о первоначальной теме дискуссии - есть ведь ещё и военный рынок. Наши позиции на нём весьма неплохи, благодаря в том числе КСЗ и сертификатам. Однако если не развиваться, то в конце концов появится кто-то ещё...
Или все таки рынок PDA для вас более перспективный?
PDA сами по себе никому не интересны. Они интересны в связки с "нормальным" :-) оборудованием. Кому нужна просто СУБД на PDA? Нужны средства синхронизации БД, разработки. Мы предоставляем кросс-платформенное решение ЛИНТЕР, LAB (естественно можно использовать не только LAB, все API присутствуют), DBSync. В принципе, больше ничего не нужно. При этом ЛИНТЕР на PDA - полноценный SQL-сервер, без каких либо ограничений функциональности, если сеть есть можно даже снаружи цепляться :-). Lite-версия, 2-3 MB памяти для работы. Вот реальный пример, нашёл случайно: http://forum.pocketz.ru/index.php?showtopic=1713&hl=%EB%E8%ED%F2%E5%F0
А DBSync можно использовать для синхронизации и с другими СУБД (Oracle, DB2, MSSQL, Sybase и даже MySQL), в он-лайн и офф-лайн режимах, транзитная синхронизация (через несколько узлов)...

Кривой рог.Линтер - отстой.
Его имеет смысл использовать только когда нужно быстро реализовать систему хранения грифованных данных.Реализовать _БЫСТРО_ схему хранения грифованых данных не получится никак, уж поверьте :-)Все остально - вечные не-до-дел-ки и вечные, никогда не выполнимые пеерспективные планы. Так что для коммерческого (я имею в виду области, где деньги зарабатывают) использования - увольте.
Насколько я понимаю, здесь идёт речь именно о ЛИНТЕР-ВС 6.0. Отчасти данное
замечание справедливо, но стоит заметить, что данная СУБД не имеет сейчас практически никакой технической поддержки и не развивается. По независящим от нас причинам, к сожалению. Она соответствует версии СУБД ЛИНТЕР 1998 года с некоторыми изменениями и правками за 2000 и 2001 годы.
С тех пор она не содержит ни исправлений, ни дополнительных возможностей ядра и утилит...
Современные коммерческие версии системы поддерживаются и развиваются.
Кстати, для совместимости с ЛИНТЕР-ВС 6.0 до сих пор поддерживается версия
ЛИНТЕР 5.7, которая имеет дополнительные программные интерфейсы, некоторые новые возможности, утилиты администрирования и конечно, исправленные проблемы.

kostyamypavelvp, хмм
а не Пасечник ли это ???
Костик, а у тебя были какие-то сомнения? :-)

Небольшая новость в тему. Если кто хочется пообщаться лично, есть возможность это сделать 20-21 апреля. Буду в Москве на конференции «Корпоративные базы данных-2005».

Сходу ответить не могу, нужно смотреть.
Пошлите вопрос в техподдержку с подробным описанием проблемы, а ещё лучше с примером. Или сюда http://www.relex.ru/mailman/listinfo/linter-list
Обязательно разберёмся.

Ситуация прояснилась. Сразу не сообразил.
Это фича. Так и должно быть - исключения на ошибку 903 в OPTIMISTIC не будет.
В этом режиме все проверки производятся в момент commit, в случае ошибки изменения откатываются и возвращается код 1600 - illegal transaction. К сожалению выяснить, что именно привело к откату, никак нельзя :-(
Это следствия специфического устройства режима OPTIMISTIC.

Что здесь можно посоветовать. Если транзакция простая и может быть только конфликт по уникальности - повесить тсключение на код 1600.
Либо перейти в режим Exclusive, тогда всё будет работать нормально.

SarinВопрос: если не секрет, растёт ли объём продаж? Захватываети ли новые рынки? Просто душа болит за отечественных софтостроителей. Интересно как у них дела.
Нормально :-) Объём продаж растёт, рынки захватытваем :-) В этом году к юбилею фирмы (две недели назад ЗАО НПП "РЕЛЭКС" исполнилось 15 лет!!!) сделали серьёзные подвижки на рынке встроенных real-time систем (QNX). Короче говоря, работаем :-)

D_N_SLНеудобная однако фича :( Это, наверное, из-за отсутствия версионности такое поведение оптимистика?
Конечно. Попытка сериализации малой кровью ;-)
В версионной версии фича [будет] пофиксена? :)
В ЛИНТЕР 6.1 такого конечно нет, как нет и собственно режима Optimistic. За ненадобностью.

Это глюк. Посмотрел, в BugTracking есть тикет на эту тему. Так что должны поправить.

Дело в том, что pdAnsDesc.Length возвращает размер бинарного представления типа в байтах. Т.е. не так, как к примеру, атрибут SQL_LENGTH в ODBC, или в OCI (который 8.x и выше). Поэтому приведенный кусок кода не верен. Нужно выделять буфер по максимуму, т.е. 12 байт (11 байт число со знаком + нуль-символ).
Сейчас ещё вспоминается мне, что при выходе шестой версии ЛИНТЕР, в связи с изменениями в поддержке кодировок и UNICODE, в LinAPI был какой-то баг с типом tString... но точно не помню, кажется к он не имел отношения к числовым данным.
Может переключится на support at relex dot ru? А то боюсь нас тут запинают :-) Да и общаться будет проще.