Re: [dba-users] Queries in Queries: new spec version

[Andrew Jensen]

Hello again Frank, Secton 1.4 of the document says " Query and Table Names Queries and tables now share a common namespace, thus must have distinct names Why? Isn't there a possibility of implementating this in such a was as not requiring a shared name space. Only the Base front end knows abou queries, the embedded engine does not. Even if you used a query name as an alias in a statement and sent it to the backend and this alias matched a table or view name there is still no conflict problem. For example, using your schema I create a query using the designer that gets all the columns from the "Orders" table, then switch to SQL view and change the select statement to: SELECT * FROM "Orders" "OrderDetails" The HSQLDB engine has no problem with this. I can run the query, update data, insert records or whatever I like. Looking at yor example in the General section of the document, line 46 SELECT * FROM "AllOrders" WHERE "AllOrders"."ShipDate" IS NULL Where AllOders is the name of a query, you show it double quoted just as if it where a valid table name. But of course you can't send this actual text to the engine, as it has no idea of what AllOrders is. Now suppose you changed the Base application so that when a query is added to a query the query name is represented differently. Perhaps: SELECT * FROM [AllOrders]  "AllOrder" WHERE "AllOrders"."ShipDate" IS NULL Here square brackets tell the parser that this is a query, not an actual table, name. The query name could still be used as the alias name since as we see above this will cause no problem to the enigne. With this type of implementation approach I dnon't think you have to worry about name space colliision problems. ( as an aside I don't want to make the same mistake I made earler when we talked about queries as views and I offered an opinion about which approach would be less risky, or take less man hours to implelement. I should aploogize for that series of messages, you know the code base - not I - you know the team members - not I - and you know what is on everyones plate - not I -. I am not sure why I really thought I could offer a valid opinion on cost of implemenation one way ot the other..) So, I am not sure if would be a much more comlicated approach, just thought I would ask - Why not this type of approach? Drew