mysql_real_escape_string / Говнокод #14508 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
PROCEDURE login_attr(a_id IN CHAR, a_pw IN VARCHAR2, v_ret IN OUT VARCHAR2)
IS
   v_count INTEGER;
BEGIN
   v_count := 0;

   SELECT NVL (COUNT (attrib_desc), 0)
     INTO v_count
     FROM tab_attr a,
          tab_users b
    WHERE a.msc_cd = b.user_dept
      AND a.attr_cd = 'CD'
      AND lattr_cd = 'ABCD'
      AND UPPER (user_no) = UPPER (a_id)
      AND UPPER (user_pw) = UPPER (a_pw);

   IF v_count > 0 THEN
      SELECT attrib_desc || '@' || user_lang || '@' || user_autoimg ||
             '@' || user_imgtime || '@' || user_loc || '@' ||
             user_dept
        INTO v_ret
        FROM tab_attr a,
             tab_users b
       WHERE a.msc_cd = b.user_dept
         AND a.attr_cd = 'CD'
         AND lattr_cd = 'ABCD'
         AND UPPER (user_no) = UPPER (a_id)
         AND UPPER (user_pw) = UPPER (a_pw);
   ELSE
      v_ret := ' ';
   END IF;

END;

Нам нужно больше селектов.

P.S. почему в предпросмотре язык Java, хотя выбран SQL?

Запостил: slbsomeone slbsomeone, (Updated )

Комментарии (10) RSS

  • > P.S. почему в предпросмотре язык Java, хотя выбран SQL?

    У Вас же PL/SQL оракловый, вот оно и намекает, что пора перебрасывать всю бизнес логику на джаву.
    Ответить
  • По-моему (но полагаться не стоит), стандарт предписывает, что если селект из одной и той же таблицы, то должен выполнятся один раз, ну, или, по крайней мере результат обязан быть один и тот же в обоих случаях (т.е. в теории должно соптимизироваться до одного селекта).
    Ответить
    • > результат обязан быть один и тот же в обоих случаях
      Зависит от уровня изоляции. В общем случае - не обязан.
      Ответить
  • Повеселила конструкция - NVL (COUNT (attrib_desc), 0)
    это ж когда каунт нулл вернуть может?

    В Oracle PL\SQL для этого случая (возвращаясь к тексту ГК) заворачивают SQL в exception, с catch no_data_found, как-то так...
    Ответить
    • > это ж когда каунт нулл вернуть может?
      Обжегшись на sum'е дует на count 😉
      Ответить
    • Врать не буду, возможно, что в каком-то AS/400 такое было проще пареной репы. Плюс, иногда могла быть ситуация, когда запрос, который должен был вернуть ноль строк, возвращал одну, с NULL'ами в каждом поле. Я так и не понял, что это было. Но костылей тогда натыкали знатно.
      Хотя, конечно, я мог что-то и перепутать, дело давнее.
      Ответить
  • более того, в результате получается мегакаша из строк, разделенных @, которую снаружи должны обратно выпарсивать...
    ref cursor ненужно?
    Ответить
    • > мегакаша из строк, разделенных @
      Очень весело будет, когда понадобится вернуть email юзера.

      Хотя мне кажется, что автор замутил бы для этого отдельную процедуру...
      Ответить

Добавить комментарий

Семь раз отмерь — один отрежь, guest!

    А не использовать ли нам bbcode?


    8