хранимые процедуры и кларион

[lsgsoftware]

СУБД MYSQL последней версии.Тут вожусь с хранимыми процедурами.
Сочинил вот такую простенькую тестовую процедуру:
create procedure test (in a0 int, in a1 int,in a2 int)
BEGIN
DECLARE a3 int;
IF a0 = 1 THEN
set a3 = a1 + a2 ;
END IF;
IF a0 = 2 THEN
set a3 = a1 - a2 ;
END IF;
IF a0 = 3 THEN
set a3 = a1 * a2 ;
END IF;
IF a0 = 4 THEN
set a3 = a1 / a2 ;
END IF;
update xxx set d = a3 ;
END
//
под монитором MYSQL все прекрасно работает.
Пробую запустить эту процедуру из клаши- все по доке:
yyy{prop:sql} = 'call test(4,42,6)'
результат - поле d в таблице ххх не меняется, т.е. процедура не срабатывает(проверяю через set(xxx);next(xxx) ).
запускаю вот так:
ххх{prop:sql} = 'call test(4,42,6)'
результат парадокcальный - клаша показывает ,что d=0 хотя в таблице ххх живет старое значение d.
Меняю в процедуре последнюю строку:
update xxx set d = 129 ;(задаю значение d явно)
Все срабатывает.
Иначе, чем глюком клаши я это объяснить не могу.
Все мы, ветераны, знаем скептическое отношение Брюса Баррингтона
к SQL, но это его проблемы. Так умеет ли клаша работать с хранимыми
процедурами или нет.
Во всех книжках пишут, что хранимая процедура - штука малтиплатформенная, т.е. она может быть написана в одной среде, а использваться в другой, что и хорошо.
С нетерпением жду ответов и советов.Заранее благодарен.
PS:
можно конечно грешить на MYSQL, но давайте прямо - по количеству инсталляций MYSQL превосходит все остальные СУБД вместе взятые
(весь инет на ней работает).Да и система в целом отличная.

[Andrew Listiev]

Ага чего только конкатенация строк стоит

[lsgsoftware]

Если кому интересно, то вроде разобрался с проблемой.Все было связано с драйвером ODBC для MYSQL. Для успокоения души крутанул
все на ASA. Все заработало. Но, ASA та еще подружка. Книг нет(есть у меня одна сверх древняя). Да, они дают бесплатную девелопер-версию на трех юзеров, а за большее требуют кокретные немалые деньги.Формально, MYSQL судя по списку в словаре клашей не поддерживается.Но, ведь я работаю через ОDBC, а это стандарт.
Если велосипедисты не научат клашу работать с MYSQL,то перспектив у клаши не будет.Ведь это самая популярная и перспективная СУБД в мире(и бесплатная)

[Andrew Listiev]

Не понимаю в чем проблема? Документация, которая идет с ASA достаточно полная, на http://www.sql.ru есть форум посвещенный именно этой базе данных. Касаемо девелоперовской версии У меня она работает на 50 коннектов и не жужу Юзай dblic.exe и будет счастье

[softcreator]

Если кому интересно, то вроде разобрался с проблемой.Все было связано с драйвером ODBC для MYSQL.
....
Если велосипедисты не научат клашу работать с MYSQL,то перспектив у клаши не будет.Ведь это самая популярная и перспективная СУБД в мире(и бесплатная)

А ты ничего не путаешь? ODBC - это просто документрованный интерфейс обмена данных. И драйвер обязан поддерживать его спецификации. И если через кучу ODBC-драйверов клаша работает нормально, а через один - криво, то кто ж виноват кроме авторов кривого драйвера?

[lsgsoftware]

И на старуху(ASA) бывает проруха.Делаю все по доке(Embedded SQL).
Вот так: xxx{prop:sql} = 'call test(4,128,2)
все рабатывает
А вот так:
b0=4;b1=128;b2=4
xxx{prop:sql} = 'call test(&b0,&b1,&b2)'
не работает, т.е. ссылки на на клашины переменные не отрабатываются.Создается впечатление,что велосипедисты
Embedded SQL толком и не тестировали и включили в доку для отвода глаз(для такокого важнешего вопроса всего 4 странички фрагментарного текста). Просьба Андрею Листьеву: если ты уж сербезно работаешь с ASA,может кинешь простенький пример хранимой
процедуры, в которую(и из которой) в качестве параметров передаются ссылки на клашины переменные.
Что касается MYSQL, то в целом с ней я работать научился.Система понимает SQL-запросы из клаши.Но если из-под монитора MYSQL через
ODBC все работает, а из клаши работает частично, то объявлять кривым драйвер ODBC MYSQL вообще-то преждевременно.

[Andrew Listiev]

И на старуху(ASA) бывает проруха.Делаю все по доке(Embedded SQL).
Вот так: xxx{prop:sql} = 'call test(4,128,2)
все рабатывает
А вот так:
b0=4;b1=128;b2=4
xxx{prop:sql} = 'call test(&b0,&b1,&b2)'

Я себя однозначно обезопасил, вызов такого рода хранимок делаю так:

Код: Выделить всё

xxx{prop:sql} = 'call test(' & b0 & ',' & b1 & ',' & b2 & ')'

не работает, т.е. ссылки на на клашины переменные не отрабатываются.Создается впечатление,что велосипедисты
Embedded SQL толком и не тестировали и включили в доку для отвода глаз(для такокого важнешего вопроса всего 4 странички фрагментарного текста).

Если используются конструкции типа IN OUT, то необходимо юзать BIND(в форуме пробегала инфа), хотя я лично не пользуюсь, пришел к другому решению. Но всё это касается только Клары

Просьба Андрею Листьеву: если ты уж сербезно работаешь с ASA,может кинешь простенький пример хранимой
процедуры, в которую(и из которой) в качестве параметров передаются ссылки на клашины переменные.
Что касается MYSQL, то в целом с ней я работать научился.Система понимает SQL-запросы из клаши.Но если из-под монитора MYSQL через
ODBC все работает, а из клаши работает частично, то объявлять кривым драйвер ODBC MYSQL вообще-то преждевременно.

См. выше. Единственно надо учитывать, что формат принимаемых значений в хранимках, должны соответствовать описанным типам.
Удачи!

[lsgsoftware]

Андрей, большое спасибо.Все сработало.Но ты только подтверждаешь мою гипотезу - Embedded SQL к реальности имеет отдаленное отношение, а проще говоря - откровенная халтура.Дождемся ли мы
от велосипедистов нормального интерфейса с SQL-СУБД.Я думаю вряд ли. А без этого подступаться с клашей к серьезным проектам, где прикладная часть ведется на нескольких средах разработки и где хранимые процедуры моут быть сделаны другими на других платформах - просто глупо. А работать на TPS -это для мелких проектов, которые на клаше делаются в одиночку.Хочу поспорить с нашим гуру(ШВС), который писал что клаша работает нормально с очень многими СУБД, а драйвер MYSQL ODBC - вроде как кривой.
А ведь всего серьеных СУБД очень мало:ORACLE,ASA,MS SQL,MYSQL,DB2, причем на РС DB2 практически не используется. Все остальное - самоделки, за которыми не стоят серьезные компании. Да , тают ряды старых кларионистов(это видно по участникам форума),
а без нормального интерфейса с SQL СУБД сегодня на рынке делать нечего.

[PIT]

Существует подобная проблема с ХП и Pervasive SQL.
ХП не работает с строковым параметром типа INOUT, с numeric параметром все Ок.

Код: Выделить всё

CREATE PROCEDURE T124( INOUT :GR VARCHAR(100) );
begin
declare :GRS varchar(100);
  print 'Input 124 = '+:gr;
  set :GRS = :GR;
  set :GRS = :GRS + '22';
  set :GR = :GRS;
  print 'Return 124 = '+:gr;
end

Ошибка: 22001 String length exceeds kolumn length. Parameter #1. Data truncated.
Помогите, кто может!!!

[Дед Пахом]

Передавать надо, судя по всему, CSTRING(не длиннее 100)

[PIT]

Даже cstring(21) не проходит. Может неправильный вызов?

Код: Выделить всё

  BIND('Ret', RET)
  BIND('GR', GR)
  MyFile{prop:sql}='CALL T124(&GR [INOUT])'
  !или второй вариант, как в helpere
  !CallProc('&Ret = CALL t124(&GR[INOUT])')
  !в этом случае ошибка другая - S1000 Stored procedure does not return a value.
  NEXT(MyFile)
  if errorcode()
     message(fileerrorcode()&'  '&fileerror())
  else
     stop('ok   '&GR)
  end

[PIT]

Проблема решена.
При передаче строкового параметра надо добавить модификатор [BINARY]
MyFile{prop:sql}='CALL T124(&GR [INOUT][BINARY])'
В этом случае никаких ошибок нет и возвращается результат в нормальном виде.