> With client/server the grid does have a role for display multiple columns

from an output set. But, whether you're using query or table

> objects, all are queries. The spreadsheet approach (TTable) is met by

SELECT * FROM ATABLE with no restricting or ordering

> capability other than, respectively, to apply client-side filters and to

borrow index definitions from the database. Quite apart from the

> traffic and the memory overhead of maxing the buffers, you have the matter

of holding these browsable datasets in an open transaction

> for uncontrollably long periods, thus preventing the database from doing

its housecleaning.

> The client/server approach is meant to be fulfilled by queries, viz.

SELECT <columns you need> WHERE <restricted criteria>. Delphi

> supports parameterised queries so there is never any need to have vast

numbers of rows parked in the client buffers. C/S UIs should be

> about supplying the means for users to select parameters and fire off

queries that return the exact dataset they want.

> So, instead of scrolling through 120,000 rows looking for Smith, Albert of

Blake St, SomeTown, an interface should have them typing

> in enough characters to provide parameters for fetching a suitable dataset

for pinpointing the sought row (ideally, a single row, but you

> can live with a small dataset of Smiths).

I think there are only a couple of places where we have a select *, but the
query is constructed with a where clause that guaruntees no rows are
returned... Mainly, I needed to get the field-definitions out, and it was a
lot quicker to do that than to try and figure out the system level tables.
I completely agree about select * from clients (for instance) being a very
bad thing to do, no matter the size of your table. At small record-counts,
it's a philosophical dislike, at large record-counts it becomes a technical
dislike as well.
However, one thing I don't like, if I can avoid it, is having the user type,
then hit a search button that will actually go out and do the query once
you're done typing. It seems ... clunky to me. What we have now is a user
starts typing on our main form (It makes sense, the way my app is
structured), and it brings up the client select form, pre-searched with the
characters they typed (Behind the scenes, it translates to select
record_id,last_name,first_name from clients where upper(last_name) like
upper('s%') currently, for the smith case). To me, (once the user figures
out that that'll happen) it makes a lot more sense to do that, rather than
bring up an empty search dialog, type in a field, hit a button, etc.
This is more turning into a UI debate, rather than an IB/FB support thing,
though.
However, I guess I'm interested in what different gui styles people are
using with IB/FB, and why they chose those, but that's a discussion for
another group, most likely (assuming that there isn't a set of GUI
components/methodology/etc that works better with Interbase than with other
SQL type servers).. Or else just email privately. :)

> btw, I think (from my experience, at least) that the need to imitate

previous software is about the worst requirement you could have to

> work with, ESPECIALLY if the system is moving from a file-based DB backend

to client/server. When you're building new on top of

> old, time spent working with users on prototyping efficient user

interfaces is money in the rainy-day account. It pays HIGH interest.

Unfortunately, our users are stupid, and can't adapt (Not to put too good a
light on them. :)).
They cry and moan that we tweaked the screen layout from the previous
version of our software to our current version.. And the current version was
released nearly a year ago.
So, it becomes somewhat necessary to emulate behavior of old software, to
avoid an avalanche of calls from angry users, flooding the tech support
guys, keeping them from helping people who are having actual problems,
rather than just complaints.
As you said, life is full of compromises. :)

> I've always been interested to survey users about why they think they want

scrolling browser-style interfaces (and I always do, because

> I have this malicious streak!). You don't have to scratch very deep to

discover that it's because they almost invariably perceive that

> "that's how computers work". That's the "intuitive" that you mention -

it's all they have ever been offered.

True... Though, there is something to be said for "That's the way it's
always been, so that's the way it'll be." User familiarity, which leads to
less of a learning curve for the program, etc., which are big points our
sales people use.

Anyways, I apologize if this is drifting off-topic for this list. :)

- Jason