At 01:17 AM 20/03/2004 +0000, you wrote:

>BUT, even taking in account we was talking about different
>situations, you can see from my logs that there is a big performance
>difference between IBO 4.2 and IBO 4.3, so something did change.
>Even IBO 4.2 is making queries on metadata. It shouldn't.

What changed with 4.3 is the query for OldParameterOrdering.

And unfortunately, all through these threads, you have been referring to
"remote access" without previously thinking to mention *how* remote, nor
that access was via ADSL. On percentages, any small change is a big change
on the protocol this represents. To me (and most people, one would
suppose), in client/server terms "remote" means "not local".

IMO, you at least do owe it to yourself to try using the SchemaCache for
these distant, slow connections. The slowness of SchemaCache is one-time,
provided you are not altering metadata frequently. (If you have a
requirement to do daily metadata changes then clearly you have an
overriding problem...)

>So, i'd like to have a position about this issue.

I've given Jason a problem description which he'll no doubt address when he
gets his land-legs back. The way I see it, SchemaCache exists there for
slow networks; and direct clients via telecom lines is a very unusual
network arrangement. With the distances and protocols in that scenario,
some people would be considering VNC or an intranet or other n-tier
architecture if it was necessary for clients to work with datasets.

I have to say that *my* position (which is personal, since I don't have any
influence on IBO's design) is that IBO should not be constrained by the
lowest common denominator (and the denominator doesn't get much lower than
this!!)

>It's serious for me, and it affects other users, too, if they try to
>access a server
>over a slow netork.

Sure: but there is "slow" and then there is "SLOOOOOOW". How many of
these "other users" would even consider trying to run 2-tier client server
across phone lines?

Helen