jkrueger@dgis.dtic.dla.mil (Jon) (11/21/89)
jbeard@quintus.UUCP (Jeff Beard) writes: >let EMP be a table containing four attributes, EMPNO,NAME,DEPT,MGR. >To use embedded SQL to access one attribute at a time, four separate queries >are required ( select ATTNAME from EMP; ). To cover all permutations requires > !4 or 24 unique queries. Correct. The problem statement, if you will. >The OCI functions {osql3,odefin,obndrv}() allow >one to specify exactly the attributes required by the user As do parameterized queries, such as are supported by INGRES Corp. Another point in the solution space. The power is identical, the functionality is identical, and the portability is identical. >Embedded SQL is just fine where the user front-end collects sufficient >information to invoke a given transaction. The mappings and implementation >are straight forward. Ad hoc browsers require more flexibility than currently >present in embedded SQL implementations. Parameterized queries allow mechanical construction and execution of parameterized screen operations that correspond to the database operations. For instance, one can build a generalized browser that acts on any database, displaying the fields presented any screen form, by consulting the system catalogs at runtime. I have done this and it works. Therefore, this would appear to offer a counterexample. In point of fact it doesn't; I used a more orthogonal query language than SQL. But the principle still applies: embedded SQL can express what is needed by browsers. Certain extensions are necessary, but their use is neither better nor worse than function call interfaces. Neither provides a very rigorous model for modifying and transforming queries, but that's another story. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?