home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / informix / 2754 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.2 KB
  1. Path: sparky!uunet!haven.umd.edu!umd5!rich
  2. From: rich@astro.umd.edu (Rich Puchalsky)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Fixes to Informix 4gl
  5. Message-ID: <17623@umd5.umd.edu>
  6. Date: 18 Dec 92 17:14:58 GMT
  7. Sender: news@umd5.umd.edu
  8. Organization: U. of Maryland @ College Park, Astronomy
  9. Lines: 36
  10.  
  11.  
  12. The worst problems I've had with Informix 4gl all involve bugs with
  13. the product.  My version of 4.1 suffers from the "out of temporary
  14. string space" WORDWRAP and USING bug as well as a core dump on INPUT
  15. ARRAY bug, other WORDWRAP bugs, and a dbload bug.  There are
  16. undoubtedly others, but I can't get a list of known bugs from Informix
  17. without upgrading my tech support.  As soon as another product emerges
  18. that I hear good things about that is put out by a compnay that's less
  19. complacent with its customers, I'm definately going to try to switch.
  20.  
  21. Until that happy day, let me report a new bug in Informix 4gl RDS 4.1:
  22.  
  23. The CURRENT function, which I use to time reports called from a 4gl
  24. program, returns the wrong time in thousandths of seconds, occasionally
  25. causing reports which take less than a second to run to appear to have
  26. run in negative elapsed time.  Here's what the CURRENT function
  27. will report if you call it repeatedly:
  28.  
  29. Hours, minutes, seconds, thousandths:   12:31:26.010
  30.                                         12:31:26.050
  31.                                         12:31:26.070
  32.                                         etc
  33.                                         12:31:26.900
  34.                                         12:31:26.940
  35.               Check this line out -->   12:31:26.000
  36.                                         12:31:27.010
  37.                                         etc
  38. At the end of every second, the thousandths of a second counter rolls
  39. from .94 to .00 while the second counter doesn't change.  That means
  40. that if you are timing something and it happens to end at the end  of
  41. a second, CURRENT will report that it ended at the beginning of the
  42. second.  If it started during that same second, then when you subtract
  43. its start time from its finsih time you will get a negative elapsed time.
  44.  
  45. I have no idea whether there are other problems with CURRENT at the ends
  46. of more important time units such as seconds, minutes, etc.
  47.