Sorry the reply is late. I do confess that the more large and compound a
post is the harder it is for me to answer. I tend to gobble up quickly those
messages which contain a single point in them. I'd rather see ten emails
with one topic each than one big email.

I'll insert some comments.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: <steve@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, November 19, 2001 11:56 AM
Subject: [IBO] Problems with generated fields


> We have spent the last few weeks testing the upgrade to IBO from BDE
> with mixed results. The project is extremely large with around 500
> screens and around 100 reports.

Sounds like an excellent opportunity to push the envelope on my claims of
quick conversions!

> The main problem we have encountered is the insistance of IBO to
> prepare everything. With the BDE, we have created many queries with
> new generated fields to allow a user-operated tick box in a grid.
> By generated fields I mean: "Select Name, ' ' FieldOne, ' ' FieldTwo
> from aTable" - the last two fields are generated.
>
> This gives a multi-select capability. Provided we made the query
> CachedUpdates = true, and dropped an UpdateSQL on the form, it was
> quite happy to allow us to edit the record (ie; allow the user to
> tick
> the box on any line), no matter what the code was in the UpdateSQL,
> or
> even if there was some.
>
> We never updated the Query so it never changed the database and was
> only used as a selection tool. Perhaps there may have been better
> ways, but this worked and is used extensively. In the conversion we
> found that IBO distregarded the UpdateSQL (something of a lack of
> understanding on our side no doubt) so we moved any UpdateSQL code
> into the IBOQuery's own EditSQL etc., creating update code where
> necessary.
>
> We now find that IBO, specifically TIBOQuery, will always attempt to
> prepare any query to the database. Is there a way that we can tell a
> query not to look at the database after the fetch?
>
> This is particularly puzzling as we now find a query that has two
> generated fields where one is used as a filter causes an error. For
> example, the SQL:
>
> Select Name, ' ' FieldOne, ' ' FieldTwo from aTable
>
> and the Filter: FieldOne <> 'T'
>
> causes an error where FieldOne is not found. In this case we are
> controlling FieldOne programatically depending on other user
> selections elsewhere.

Unfortunately, this capability is not likely possible. IBO is built to
harness the full power and potential of InterBase. As a result, it is built
to work directly with the server and has nothing more than buffering
capabilities between the client and the server. Previously, the BDE would
actually pull data down from the server and then it would store it in local
database tables. As a result, it would allow you to do fairly involved
database operations right on the client with the buffered data. While this
provided you with some flexibility, it was also because the BDE was this way
that it was considerably slower than IBO and a lot less flexible in other
very important areas.

One example, I don't have a full 100% SQL parser in IBO, I simply rely on
passing statements to the server to have them prepared. As a result,
everything is parsed through the server rather than on the client. The
handling of Filter text is parsed and resolved to InterBase SQL rather than
operations on a local buffer. Thus, in some ways this makes filter
processing much faster but it makes it so that you cannot do what you have
been doing in the past.

What you could do is take advantage of the OnFilterRecord event to do the
same thing and then you get filtering capabilities on the client. You also
don't have to refresh records from the server if you use RefreshFilteredRows
if you determine that the logic the filtering is based on has changed. So,
with some modifications, you can have the system you had before and still
keep all the performance and efficiency advantages IBO brings you. I am
confident it will be worth your efforts.

> Many thanks
>
> Steve Peacocke
> steve@...