I understand your frustration Fabiano. My current userbase is spread out
over an entire continent, and only this year did we start using DSL. Most
sites used 56K frame relay, or even 16K dialup. Our company is not small -
revenues are over $2B per year - nevertheless this was exactly what our
company was doing. This practice is much more common than Helen suggests,
but it is also why "client server" (unfairly) got a bad name in the
industry. This is not the appropriate environment for a 2-tier client
server architecture.

At my prior employer, our "remote" sites were so remote that the last thing
we put up before leaving was the tower for the cell phone repeater. The
repeater itself would become operational about two weeks after we had
actually left the site. If we were lucky we had cell phone dial-up, but
most often it was fastest to send a truck to the office with the floppy
disks and do a merge once a week. I built my midware piece out of flat
files and FTP, which gave me lots of flexibility and made optimum use of
available bandwidth and resources.

Traditional "Client Server" is too chatty and too dependent on
communications for reliable or fast operations with our environment.
Nevertheless, many of our bosses have read too many "glossy one's" and we
are constrained by our paymasters. You probably understand how frustrating
it was to get across the idea that caching static information at the user's
workstation was necessary ... until people refused to use the product
because it took their location over an hour to launch each day. Firebird is
good, but it isn't magic - it's still a traditional client server tool and
it is fairly chatty compared to batched files via FTP, no matter what
interface mechanism is used.

I suggest an architecture change, using a midware piece to talk to the DBMS
at the server end, and a mix of caching and "store and forward" techniques
at the client end. Firebird could even be distributed to the clients for
the "store" part of the store and forward system, giving a solid,
transparent, and secure failover mechanism.

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, March 19, 2004 5:39 PM
Subject: Re: [IBO] Re: For Fabiano Bonin


> 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
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
> Yahoo! Groups Links
>
>
>
>
>
>