>> >I have a problem where an VB application have to make query on
>> >an access table stored in a remote NT server. The communication
>> >line is only a slow telephone line with 33.4K. Due to budget
>> >limit, we are not afforable to buy a SQL server.
>> One approach would to be to create a remote OLE automation server that
>> run on the remote computer, accepting requests to run queries, and
>> only the results. You need VB4 Enterprise (or VB5 Enterprise) to do
>Geez, I don't know about this. The tests I did with Remote Automation and
>DCOM indicate a fairly high minimum overhead, about 1KB, for every method
>or property call. There's also the synchronous execution issue. I wonder
>if something like Sybase SQL Anywhere would be a better choice.
It's _another_ choice. I have an entire SQL scripting language system based
on such the scheme mentioned above, because it yields a real performance
benefit. The overhead of out-of-process OLE, the network, etc., is
negligible compared to the time and resources consumed by the database(s).
There's going to be more overhead running over a modem line, but A) The big
overhead -- getting the resultsets back -- will be roughly the same no
matter what mechanism is used to retrieve it, and B) With a decent
connection and a well designed system, you're looking at a relatively small
number of 1/2 second calls, a time, again, which may be negligible compared
to the time it takes to query for and send the data.
The big question is what kind of query activity is being considered. If it's
a slew of quick, 1-row queries, then remote OLE might _not_ be the _best_
alternative. On the other hand, if it's a bunch of big update queries, or a
bunch of fire-hose selects, the OLE overhead won't be a factor.