home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / oracle / 1095 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.5 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!cc.helsinki.fi!jaakola
  2. From: jaakola@cc.helsinki.fi
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Referencing a SEQUENCE from a trigger...
  5. Message-ID: <1992Jul21.173241.1@cc.helsinki.fi>
  6. Date: 21 Jul 92 15:32:41 GMT
  7. References: <1992Jul20.195514.8085@unixg.ubc.ca>
  8. Sender: news@klaava.Helsinki.FI (Uutis Ankka)
  9. Followup-To: comp.databases.oracle
  10. Organization: University of Helsinki
  11. Lines: 47
  12.  
  13. In article <1992Jul20.195514.8085@unixg.ubc.ca>, george@unixg.ubc.ca (George chow) writes:
  14. > I've got a situation where I need to insert rows into a table in a 
  15. > ON-VALIDATE-FIELD trigger. For these rows, I need a serial no which I'm
  16. You can't execute DML statements (inserts, updates, deletes) from an
  17. ON-VALIDATE-FIELD trigger. You should think how you could do the job in
  18. transactional triggers (pre/post-insert/delete/update etc). Or you have
  19. to do your insert through the base table mechanism.
  20.  
  21. And using ON-VALIDATE-FIELD trigger is bad choise because it may happen
  22. that the trigger gets executed many times, each of which grabs another
  23. sequence number; and the user might rollback any changes, which leaves
  24. gaps into your serial numbers. The gap problem is inherent with
  25. sequences, but that's acceptable here, right?
  26.  
  27. > getting from a SEQUENCE. However, I can't seem to reference the SEQUENCE.
  28. > I'm doing something like:
  29. > 
  30. >   new_ref := :SEQUENCE.V_REF_NO_SEQ.NEXTVAL;
  31. Try to rethink this by using transactional triggers. There, if you are
  32. not inserting via the base table mechanism, you can write:
  33.  
  34.   INSERT INTO the_table (serial_no, ...)
  35.   SELECT v_ref_no_seq.nextval, :block.fieldname, ...
  36.   FROM dual;
  37.  
  38. Maybe INSERT ... VALUES would do as well, look at the manual. This is
  39. clean and avoids the PL/SQL variable new_ref. In my opinion, having many
  40. scratch variables decreases readability and is not in 4GL spirit. This
  41. solution obviously has the drawback that you have no way of knowing what
  42. number just got inserted. If you really want to know that, use SELECT
  43. v_ref_no_seq.nextval INTO new_ref FROM dual. The original assignment
  44. statement is illegal, because you can reference sequences only in SELECT
  45. column expressions.
  46.  
  47. > 
  48. > which gets me the error messages:
  49. > 
  50. >   PL/SQL error 49 at line 10, column 16:
  51. >      bad bind variable 'sequence.v_ref_no_seq'
  52. > 
  53. > I've gone through the _SQL Language Reference_ and _SQL*Forms Designer 
  54. > Reference_ and I can't find anything useful there. Is the ":SEQUENCE."
  55. > syntax only valid for use with default value? 
  56. Yes.
  57. --
  58. Juhani Jaakola
  59. jaakola@cc.helsinki.fi
  60.