Bill, I think we all know that it is unlikely for this facility/these facilities to simply "appear" within U2 - certainly within the core product, because it would "break" to many existing applications, and require to people to make changes to (or even CREATE!) dictionaries, code etc.
I agree that it would be a "good thing", but I think the reality is that it is not going to happen ..... and if it DOES happen, for backwards compatibility they will have to keep things the way they are, and that will let people by-pass your rules & do "nasty things". There were some other points by other posters about having to "do things" to create triggers etc .... you CAN overcome this by simply not using the "standard" create-file, but instead use your own. Then, when a file is created, you can also hook in some standard triggers - it IS possible to write a single trigger routine that can be used to enforce referential integrity .... BUT, you need to have some extensions made to the standard U2 dictionaries to be able to flag things like "this is a mandatory field", or "this is the @ID on another file, and it MUST validate against that file" HOWEVER, your code that 'writes' (or reads) from a file then also needs to be updated so that it reacts 'appropriately' to the error conditions raised/reported As others have pointed out, with constraints, rules etc as an integral component of the overall environment, the amount of "real code" that has to be written can be drastically reduced, which translates (what pun?) into increased productivity, more robust applications, and a single source for integrity rules (the dictionary to the file rather than the myriad programs that update it) Ross Ferris Stamina Software Visage an Evolution in Software Development >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Bill H. >Sent: Wednesday, 19 May 2004 1:06 AM >To: [EMAIL PROTECTED] >Subject: RE: [U2] Cost of Oracle vs PICK > >Ross: > >As we know, mvDbms products (other than U2) have security built in (see >D3). >It was often not used, however. We can only hope the U2 products address >this issue (not through SQL) since mvDbms development relys on the >applications developer and the business expert. I guess that's sort of the >origins of U2 - Unix, where security is accomplished via the O/S system >administrator, which is not an advantage to the application developer. > >An mvDbms was designed to be used by an application, and be managed by that >application, not the other way around. This is understandable since the >development group usually has a better idea of who and how access is to be >granted. > >Remember, an mvDbms is both a database and an application server in one and >this is an advantage. Universe has provided transaction processing and >triggers. Some internal security would be nice too. > >Bill >------- >u2-users mailing list >[EMAIL PROTECTED] >http://www.u2ug.org/listinfo/u2-users > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.687 / Virus Database: 448 - Release Date: 16/05/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.687 / Virus Database: 448 - Release Date: 16/05/2004 ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users
