Hi Andrew, > Third - QiQs. Well, here I have had a number of problems. Mostly it > seems to work, but I have not been able to get any derived query to use > a parameter at all.
>From your example below I see that you're using named parameters (:Id), while in my tests, I used unnamed ones (?). The latter work, the former don't. Interestingly, named params work fine if they're not part of the inner, but of the outer query. Hmm. Will put this onto the list, thanks for finding. For your continued testing, you might want to switch to unnamed params. > This doesn't seem to matter if the parameter is in > the outer select or sub-select part of the statemet. It appears that > when it is a 'derived' query then the parameter is not being replaced > when sent to the database engine. The dialog box prompting for the > replacement value runs - but the error statement, which I believe is > being reported from the engine actually shows the paramter, not it's > replaced value. The statement always shows the SQL string, not a "pre-processed" version with substituted parameter values, so this is no indicator. (Creating such a version of the statement would be extra work, it doesn't exist: Usually the statement is parsed and compiled, and then the parameter values are used as needed. At no point in time, there does exist a statement with parameter placeholders substituted with their actual values.) > Third - error messages. This is a subject I had not even thought about > in our earlier discussion about derived queries as sub-selects. > ... > Now, this example is fairly easy - I did not aliases column names in the > base query for example. But I am worried that users are going to get > very confused if the statement they see in the error box is so darn > different from the one they see in the builder. Which brings me back to > a question I asked in our previous discussion. Should there be some way > for the user to see the statement that will actually be sent to the engine? Hmm. Do you have an idea how this could look like? The only place I could imagine is the error box itself (behind the usual "More" button). Problem is that such a query can be executed from arbitrary places (including from within Writer and Calc), and the only thing they have in common is that in error case, the message box is raised. So perhaps some additional explanatory text in the list which opens up upon "More"? What do you think? (Adding this to the open issues section of the spec for the moment.) Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
