home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / oracle / 1482 < prev    next >
Encoding:
Text File  |  1992-09-03  |  3.3 KB  |  107 lines

  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewse!cbnewsd!att-out!cbfsb!cbnewsb.cb.att.com!colten
  3. From: colten@cbnewsb.cb.att.com (marc.colten)
  4. Subject: Problems in olsqlforms30 and OCI (in C)
  5. Message-ID: <1992Sep3.163521.26698@cbfsb.cb.att.com>
  6. Keywords: FORMS, ORACLE, C, OCI
  7. Sender: news@cbfsb.cb.att.com
  8. Organization: AT&T
  9. Date: Thu, 3 Sep 1992 16:35:21 GMT
  10. Lines: 95
  11.  
  12.  
  13. Well here I am again.  I've been using olsqlform30 to create forms
  14. and the OCI (in "C" language) to insert and extract information.
  15. I've been hitting some problems and would appreciate some advice.
  16. Please e-mail and responses and I will summarize and post.
  17.  
  18. thanks in advance,
  19.  
  20. marc colten
  21.  
  22.  
  23. 1)  I created a table with a LONG field for comments.  I can
  24.     add and edit that field just fine (I have a 
  25.     ON-NEW-FIELD-INSTANCE trigger with EDIT_FIELD in it).
  26.     However, my C program will not extract that field in any
  27.     way.
  28.  
  29.     Some code is :
  30.  
  31.      struct {
  32.             ...
  33.             ...
  34.             ...
  35.             ...
  36.             ...
  37.         char TROUBLE[65535];
  38.         } attr[3];
  39.  
  40.  
  41.      odefin(C0,5,attr[1].TROUBLE,(int) strlen(attr[1].TROUBLE),LONG,
  42.                    -1,dum,NULL,-1,-1,&dum2,&dum3);
  43.  
  44.     
  45.    When I fetch the data, everything else comes up okay, but
  46.    I get a message that the field has been truncated.  I
  47.    print it out character by character (assuming it was not
  48.    NULL terminated) and it's empty.  I have tried putting the
  49.    field length directly into the odefin, and the field length
  50.    in the structure has been anywhere from 100 to 67000.   I have
  51.    used LONG and STRCHR as identifiers.  Nothing.
  52.  
  53.  
  54. 2) I have used structures with no array:
  55.  
  56.      struct {
  57.             ...
  58.             ...
  59.             ...
  60.             ...
  61.             ...
  62.         } attr;
  63.  
  64.  
  65. and it does not work.  If I use attr[3], I can't get the
  66. data into attr[0].  But if I use a number > 1 and assign
  67. the output to attr[1].<field>, it always works.  Can anyone
  68. explain this?
  69.  
  70. 3)  Can you do a query on a detail block and have the relevant
  71.     information come up in the master block?  It works fine
  72.     the other way.  I do a query in a master block and it brings
  73.     up two records in the detail (which it should).  I've tried
  74.     doing the reverse and it won't work.  I set up a KEY-ENTQRY
  75.     trigger on the detail block with various commands:
  76.  
  77.          go_block('<master>');
  78.          :<master>.field := <detail>.field;
  79.          execute_query;
  80.     
  81.     But no luck.  execute_query wipes out the master block
  82.     before it does anything. What I wind up with is the
  83.     detail block shows the information what I wanted, while
  84.     the master block shows the data you'd get from a blank field.
  85.     
  86.     What I want to do is:
  87.         enter the query in the detail block.
  88.         execute the query.
  89.         The master block queries it's table to come up
  90.           with the appropriate information based on the data
  91.           placed in the detail.
  92.         The master executes a query so the master and the detail
  93.           (two records now) show the matching data.
  94.  
  95.     Is this possible?
  96.  
  97.  
  98. 4)  Can you do a LOV on a block, or failing that on a non-enterable
  99.     field?  I just want a list relevant to the data I've queried
  100.     as an alternative to a second page, which is not really necessary
  101.     and really slows things down.
  102.  
  103.  
  104.  
  105. Thanks
  106.  
  107.