> 44 параметра в процедуре!!!

Что, серьёзно?

Иногда хочется так же сказать про 1С...

обидно да? 44 параметра передал и не одного не вернулось :)

Ха! 44 параметра - это так, мелочи.

У них там есть и за 80 параметров.

Встречу проектировщика этого "программного интерфейса" - слово "у&^%ок" будет самым добрым.

> 44 параметра передал и не одного не вернулось

Я соврал - там 45 параметров, из них 43 на in и 2 на out :-)

>44 параметра в процедуре!!!

фортран77? Помнится, у меня там было и больше =)

Пользуйте Фигаро. Правда она для очень крупных предприятий. Там даже Гуя нету. Как факта.

> 44 параметра в процедуре!!!

Круто. Но это не предел.

У нас как-то на кафедре преподы учения проводили - распечатывали функции и раскладывали всё это на полу в коридоре. Победителем был хозяин 25 метрового монстра.
Пишут видимо какие-то отчисленные за не успеваемость первокуры. ИМХО оптимальное кол-во параметров 4-5.

> Но это не предел.

Увы... Уверен, в глубине этой лужи я еще и не на такие перлы нарвусь...

Как выглядит штатный (фактически рекомендованный "разработчиками"!) способ узнать откуда берутся соответсвующие данные? Думаете, почитать документацию??? Щас!

Запустите SQL-монитор и в нем посмотрите запрос - и специально для этой цели SQL-монитор встроен в дистрибутив! Сервис типа :-)

>44 параметра в процедуре

в программной инжинерии это называется кризисом 'разделяй и властвуй' :)

ты об этом?

Разочарован отсутствием упоминания биореактора. Зря я что ли столько лет тут всех лечил?!?

> Запустите SQL-монитор и в нем посмотрите запрос - и специально для этой цели SQL-монитор встроен в дистрибутив! Сервис типа :-)

Ха-ха. Это мне даже слегка понравилось. Есть некий смак в таком подходе. Действительно, чем читать доки, поковыряйтесь отладчиком и вам всё ясно будет. :-)))) Известно, что за редким исключением программисты питают отвращение к написанию документации, а самодокументируемые программы существуют не для этого случая. Вывод: программисты на фирме есть, а доки писать некому. 44 параметра -- это сильно. Там что структурных типов никаких нет?

Да тут не то что в биореактор - таких в зародыше надо сливать.
Ёпть это-ж даже школьникам паскалевским ясно что так не пишется!

фигня.
я вон видел процедуру на скуле, дык там 354 (не вру!) параметра.
могу показать :)

> фигня. я вон видел процедуру на скуле, дык там 354 (не вру!) параметра. могу показать :)

Спасибо, не надо. На сегодня хороших новостей достаточно.

Я хочу крепко и безмятежно спать, и не умереть от хохота.

"Краткость -- сестра таланта"(с) Но, помня, что "талант" -- это наименование древнегреческой денежной единицы, а программистам платят за количество строк кода... убеждаешься, что в семейке царит, отнють, не мир.

Это в public API? 8)

Именно в паблике :-) Том, который p_xxx_insert, а не p_xxx_base_insert :-)

Да уж лет 10 как никто за строки не платит...

Оплатим грамотных программистов, исправляющих ошибки девелоперов "Корпорации Парус" и пользователей ПАРУС-8хх

Оклад - минимум от 600 грин (отличное знание PL/SQL и Crystal Reports) Знающим предметную область и прочие науки - от 1000 грин. Работа - в Москве. Знание Linux - приветствуется. Знание Oracle 8 и 9 - ОБЯЗАТЕЛЬНО. Имеющим вышеперечисленные знания и опыт руководства проектами - свыше 1200 грин.

Резюме присылать на job8@mail.ru.

> Оплатим грамотных программистов ...

Тра-та-та! "Парус" - одна большая "ашипка". Его чем исправлять - легче переписать :-) Так что маловато будет :-)

P.S.: я знаю кристал на уровне "воткнуть поле/готовую формулу", за кодинг SP без книжки не сажусь, правда с ораклом неплохо знаком - но и то считаю такую зарплату ниже своего достоинства :-) Тем более в москве :-)

>>P.S.: я знаю кристал на уровне "воткнуть поле/готовую формулу", за кодинг SP без книжки не сажусь, правда с ораклом неплохо знаком - но и то считаю такую зарплату ниже своего достоинства :-) Тем более в москве :-)

Ужрался...

Хотя когда копаешся в "навозе" никакая зарплата не поможет.

Есть у меня знакомые серди девелоперов Паруса, но они не виноваты в этом, так как стиль программирования который применяется в данной конторе можно охарактеризовать одним словом АТАС :)

Расскажи :)

> но они не виноваты в этом, так как стиль программирования
> который применяется в данной конторе можно охарактеризовать
> одним словом АТАС :)

Фиолетово. Пользователи видят только результат, поэтому от этого им не легче :-(

А это, наверное, из за того, что каждое поле таблицы описывается отдельным параметром. вот и получается такая лажа. По другому организовать процедурный интерфейс с ораклом достаточно проблематично - только через составные типы, чоторые нормально работать стали только года 2-3 назад. А Парус - прога старая.

С другой стороны удивляет использование бде.

Скоро иам бде не будет. только вот кому от этого станет легче? :)
Вот шестой проект у них без бде, шо думаете скорость выше? щщщщаз...
а вообще, Парус - как контора - помойка. Не имхо. Один саппорт чего стоит.

Ха! Если б ЭТО была единственная проблема !!!  SQL-запросы там ТАК КОНСТРУИРУЮТСЯ !!!
Например: Самая распространённая задача - посмотреть ненулевые остатки на складе:

SELECT *
    FROM v_goodsparties m
   WHERE ncompany = :1
     AND nrn IN (
            SELECT nprn
              FROM v_goodssupply
             WHERE ncompany = :2
               AND nstore IN (SELECT rn
                                FROM AZSAZSLISTMT
                               WHERE azs_number = 'Склад XXX')
               AND nrestfact >= 0.001)
ORDER BY scode

где:
v_goodsparties - вьюха, состоящая из 15(!) таблиц и ещё одной вьюхи!
v_goodssupply - вьюха, состоящая из 6 таблиц и ещё одной вьюхи!

Выбирается это ЧУДО - на 8(!) серверных ксеонах - не меньше минуты!
Руки бы поотрывать.
И, главное дело, исправить-то НИКАК НЕЛЬЗЯ! В принципе! И сами не исправляют - сколько не писал! Им, по-моему, всё пох@й!
ПОУБЫВАЛ БЫ СВОЛОЧЕЙ !!! 


Я уже не говорю про интерфейс клиентской части. Например, в том же разделе, Товарные запасы:
Чтобы выбрать Остатки по конкретному складу, >0, нужно попрыгать по ТРЁМ закладках в условиях отбора - где ж эргономика?
Я уже не говорю, что невозможно выбрать все НЕнулевые остатки (>0 и <0) вместе.

Мудаки, короче.

Гы )

Ну да, работа с данными через вьюхи очень даж прикалывала %-)

>Известно, что за редким исключением программисты питают отвращение к написанию документации [...]

Говоря вообще, это естественная ситуация: кто может писать программы, тому некогда писать книги. Спрашивается, кто пишет книги? :) (оговорка: есть приятные и РЕДКИЕ исключения)
-- Thorn (linuxnews.ru)