Andrew Jensen wrote:
Of course wouldn't one then still need seperate icons to
differentiate them? Perhaps though I am missing a point here. Is
there any difference now between a table, a view and a query in the
context of the query designer?
Not to me, anyway. :)
Hi Fred,
I wonder, may I ask what about this feature is so important? You said
in an earler post that you have a bunch of queries derived from other
queries in MS Access. That you would like to move to Base, but must be
able to transfer these style queries. As was pointed out earlier you
can turn queries into views and derive queries from them now. So what
I am wondering is this - is there some other functionalilty that is
actually missing, or is it just an irritant ( the creating a view step
) that needs to be removed?
For example - a few people on the forum have brought this issue up. In
some cases showing them how to do this using views was satisfactory in
others not - Why? Well, mostly because, for those that did not find
the use of views satisfactory what they really wanted to do was have a
query that joined columns from more then one table and then have that
query be fully updatable - meaning they could write data to any of the
columns in any of the tables. In a couple of cases what they wanted
was to have replacable parameters in the query that formed the bases
of the new query. In either of these cases the use of views would not
work. But simply basing queries on queries does not necessarily solve
either of these situations - at least I don't think it does, or more
properly put, it may not if it is not part of the requirements.
One item I find interesting because of its absence from the
"Queries_in_Queries" document that Frank has put together is the
motivation for adding this feature. I am wondering if some might be
looking at this as what I would call a 'Cost of entry' feature -
meaning, our competitor has it, therefore we must have it in order to
be considered. A valid point often, but only if the benefit of the
feature is fully understood. In fact simply look at the way Issue
51143 was entered :
"The competiting product allows queries to be created based on existing queries.
However, OpenOffice.orgBase only allows queries on tables."
Well, point in fact is that the second sentence above is incorrect,
Base allows queries on tables *and views*. It may well be that the
curent user interface, and lack of decent documentation for the Base
module, is as much at fault here as the missing feature, unless of
course this is just an abbreviated way of asking for other features
that are not currently fully supported. To be honest, that is what I
suspect here.
So Fred, I wonder if you would be so kind as to offer an example of a
query derived from another query, which you creaed in MS Access that
can not be duplicated in Base using the technique of converting the
foundation queries to views first. It may be quite useful to
understanding the best way for Frank and his team to proceed. In the
end perhaps it is just nomenclature and removal of an intermediate
step that will be the benefit of this new feature, I am not sure.
I really don't mean to pick on you Fred - perhaps someone else reading
the list could supply this example instead.
Drew
Darn, Drew. You scared the livin' daylights out of me. Have never had
anyone address me directly like this. In response to your question(s).
In the first place, it's pretty hard to answer these questions because
at work we pretty much put the db together and then just work with it.
Once we set it up we almost forget how we put it together. i think the
main -- if not the only -- reason for the request was bec. it was the
way we had used to set up the db in Access. We don't really know enough
about dbs to know what we should or could be asking for. The main thing
we used this for was what you mentioned above: the ability to be able
to update any of the columns. The other thing which we use quite a bit
is the replaceable parameters option.
i hope this helps. We literally spent probably hundreds of hours
developing our own system. It's not very big and only needs to handle
maybe some 1500 records. We use it to provide child care and basically
link parents, children and providers and track some ten million taxpayer
dollars a year in child care expenses.
Have a great evening! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
