Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!tank!supp From: supp@tank.uchicago.edu (Steve Upp) Newsgroups: comp.databases Subject: Re: Referential Integrity in commercial DBMS's? Message-ID: <5390@tank.uchicago.edu> Date: 13 Sep 89 21:15:50 GMT References: Reply-To: supp@tank.uchicago.edu (Steve Upp) Organization: University of Chicago Lines: 71 In article bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: >At a meeting of the Western PA Ingres Users Association yesterday, we got >a brief preview of version 7.0. Among other things, Ingres 7.0 will include >rules, which are stored procedures executed in the manner of triggers on >UPDATE, INSERT or DELETE. The description we got sounded really slick. >Projected ship date is sometime this quarter. This is particularly scarry to me. I've been using Ingres 6.2 (VMS 5.0) this summer to write up a straightforward database system for a department here at the University of Chicago and have found Ingres an occassionally frustrating system to work with. I can (but won't now, unless many people would like to see it) show you a select statement in 4GL of ~15 lines (I don't remember off hand) that is guaranteed to completely crash Ingres 6.2's back end. I mean completely crash it - as in dead, gone, outa here! You'll have to run ii_startup.com to get it back up again. In our pursuit of a solution to this problem it comes out that RTI had a bug report on this problem that goes back to version 6.0 (a year ago)! They just never got around to fixing it. I went to a local users group meeting to bring up this topic for discussion and was amazed at how nonchalantly most people took this. If the backend crashes who knows what state your data will be left in! That should matter if you are running in a production environment (like we will be here). Luckily, I was the only person using 6.2 on this machine at the time. AS A SIDE NOTE: If you have the disk space (and not everyone does) it is a very good idea to run two copies of Ingres 6.2 at the same time. One for development only and the other for production systems otherwise you may find yourself in a heap of trouble like the above describes. My complaint is that RTI SHOULD NOT come out with yet another "really great" version of system enhancements when their system has reported bugs that aren't getting fixed. To me, stability is the key to any companies success not just bells and whistles. I'm sure RTI people on the net are going to scream loudly about this! They do seem to defend their product strongly. And I'm sorry if I'm putting RTI on the spot here, but this kind of thing really does irk me. The response I got from a 'salesman' at RTI was that these problems are all being handled with sufficient effort and that the new bells and whistles are added by a seperate group of people. In my view some of those people should be moved over to the bug fixing group before version 7.0 is released. I know that on any new piece of software that has been rewritten like Ingres 6.0 has, there will be problems, that is one thing. But to continue to produce bell and whistle versions while not fixing major problems like this one quickly RTI runs the risk of alienating their user community. I am not our site's Ingres administrator, I don't deal directly with RTI nor do I speak for the University of Chicago. I'm just a summer employee who wrote a program with an RTI product. I'm only giving you my own personal reactions to RTI's plans of a version 7.0 and I couldn't believe it when I heard it! On the positive side, the system I have written does work. I like the features of 6.2 over our previous 5.?? version I just wish RTI would get its act together on bug fixes.... Also I'm not certain of the current status of that bug, I just coded around it and went on.... ---- Steve Upp InterNet: supp@tank.uchicago.edu University of Chicago University Computing Organizations