home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19800 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.4 KB  |  53 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!pacbell.com!unet!porsche!nowacki
  3. From: nowacki@porsche.net.com ( Michael Nowacki I.T. Database Contractor)
  4. Subject: Re: cdd, c, and rdb 4.1
  5. Message-ID: <1992Dec23.193113.12390@unet.net.com>
  6. Sender: news@unet.net.com
  7. Nntp-Posting-Host: porsche
  8. Organization: Network Equipment Technologies, Redwood City
  9. References: <9212231344.AA20322@top.magnus.acs.ohio-state.edu>
  10. Date: Wed, 23 Dec 1992 19:31:13 GMT
  11. Lines: 40
  12.  
  13. In article <9212231344.AA20322@top.magnus.acs.ohio-state.edu> Ung-Ho Yi <ungyi@magnus.acs.ohio-state.edu> writes:
  14. >thank you to people who have responded to my c and cdd question.
  15. >
  16. >some one asked what the DEC said about my problem.
  17. >i only spoke with one technical support person, and he said i
  18. >should create another record for C language, which is the same advice
  19. >i got from most of you.
  20.  
  21. one alternative would be to declare an integer in cdd that is the length
  22. of the data element, so that routines that need to declare buffers for
  23. the field in question can do the equivalent of
  24.  
  25. char[sizeof(CDD_INT) + 1] buffer_fld;
  26.  
  27. then you would have to have the 'c' source code ( a header file) declare
  28. all the 'c' versions of data. you have to have 2 different mechanisms to
  29. provide the same field in different languages. this option allows one field
  30. and 1 size descriptor, rather than 2 distinct field definitions suporting
  31. the same domain. just an alternative, they both are a nuisance.
  32.  
  33. >I would also like to respond to the rdb v4.1 because we just went 
  34. >through with much difficulty.
  35. >
  36. >first was segmented string.  i am not sure about the exact problem,
  37. >but here it goes.  our application program first stores 3
  38. > bytes as segmented string,
  39. >then later on the program adds more data on to the segmented string.
  40. >this has always worked with rdb v4.0, but on rdb v4.1 it corrupted
  41. >our database.  the DEC engineers had manually remove the bad pages.
  42. >
  43. >second problem was with selecting rows.  i heard this has to do with the
  44. >optimization of the rdb....  some how, when we select rows and
  45. >sort by some order, the query becomes very slow, much much slower then
  46. >when we were using rdb v4.0.  so, we had to change some of our application
  47. >programs again.
  48.  
  49. this news group is a great place to share the gory details of the querys 
  50. involved and the indexes on the tables.
  51. Did DEC concede that theses are bugs and not side effects of the architectural
  52. changes in 4.1?
  53.