We're doing a product comparison for graphical query builders. Would
appreciate
your input on what you like (or don't).

We're an Oracle shop, but we need connectivity w/ any ODBC compliant
DB.
Also need query result export options (esp Excel), pivot capability,
printable results,
Windows compliant.

We don't need write capability, and if the tool has it, we need
to be able to turn it off. DB Admin tools not needed.

I've heard great things about AQT (Advanced Query Tool)... comments?

Thanks,
Carol

carol_marra (AT) msn (DOT) com wrote:
I think all of the tools are bad. They produce simplistic queries,
poorly tuned, and hide from the end-user the information required
to do the job well.

Better to invest the money in good training than in a dumb-as-dirt
GUI.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

carol_marra (AT) msn (DOT) com wrote:

David Segall wrote:
I can't think of a worse tool.

The last thing Oracle needs is to be connected to an insecure (ODBC)
tool that could potentially be used to alter data and in which you
couln't write a decent SQL statement more complex than SELECT *
FROM t;.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

DA Morgan <damorgan (AT) psoug (DOT) org> wrote:

everybody has Access on their desktop.
query builder but I doubt if anybody who would deign to use a
graphical tool would reach them. If by "decent" you are referring to
the generated SQL I have no way of comparing it to your other
contenders. I confess that I have felt the need to simplify Access
generated SQL when I have used it in a program that somebody else
might have to modify.

David Segall wrote:
Referring to the fact that the following query would be impossible
to write:

WITH w AS (
SELECT person_id
FROM person
WHERE per_fmw = 'Y')
SELECT per_h_email
FROM person p, w
WHERE p.person_id = w.person_id
AND p.per_ok2_email = 'A'
AND p.per_h_email IS NOT NULL
UNION
SELECT po_w_email
FROM poie o, w
WHERE o.person_id = w.person_id
AND o.po_status = 'A'
AND o.po_w_email IS NOT NULL;

I would write dozens of other basic statements impossible to
duplicate in MS Excess.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

On Sep 18, 1:37 pm, carol_ma... (AT) msn (DOT) com wrote:
Any other comments here? Yes, I know there are limitations, but I
do agree it's unlikely that any of our users will hit them.

carol_marra (AT) msn (DOT) com wrote:
Then train your users.

If your users are so inexperienced with SQL that they can only write
basic statements, and likely poorly tuned ones, you are doing them
and your organization no favor.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

You appear to be totally disconnected from the real world - probably what
comes with teaching too long.

If you had any current industrial experience, especially in investment
banking then you would discover that Access (albeit a pain) and Excel for
that matter are both successfully being used by sales traders, salesman and
analysts throughout that industry as a database tool.

--
Tony Rogerson, SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson
[Ramblings from the field from a SQL consultant]
http://sqlserverfaq.com
[UK SQL User Community]


"DA Morgan" <damorgan (AT) psoug (DOT) org> wrote

In the same way that First and Last is somewhat difficult in Oracle no
doubt.

Not that I defend Access but frankly I think you need to wake up and realise
that a significant number of people don't use oracle.

--
Tony Rogerson, SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson
[Ramblings from the field from a SQL consultant]
http://sqlserverfaq.com
[UK SQL User Community]


"DA Morgan" <damorgan (AT) psoug (DOT) org> wrote