Hi Frank,
First - the icon for views. Nice. I think the arrow is a nice clue that
this is a one way only item. The dialog box for the query designer was
just as you had described in your document. It is simple and straight
forward.
Second - Regression testing . I took a large number of odb files,
created from help sessions at the forum, with various queries and ran
them using the 'qiq' build. There was not a problem with any of them, or
put another way - it seems that what did work, still did and what didn't
still didn't.
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. 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.
Third - error messages. This is a subject I had not even thought about
in our earlier discussion about derived queries as sub-selects.
For example: I had a query that joins three tables, I saved that query
as 'qContactProjects' then based another query on this one and added a
parameter. So the query in the builder reads as : SELECT "ContactID",
"ProjectID", "ProjectName", "ProjectBegin", "ProjectEnd" FROM
"qContactProjects" AS "qContactProjects" WHERE ( ( "ContactID" = :Id ) )
If I run the query, then as I said before, I am prompted for :Id but an
error message box appears with this text ( see attached image )
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?
Sincerely
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
