Re: Performance of ODBC

Tech-Archive recommends: Fix windows errors by optimizing your registry

for the record; you could always terminal services on an Windows XP
Professional machine that was running MSDE.

I just disagree; yes the probem is MDB. Using ADO .Find methods and all
that client side crap is bull***. the problem is that you're having
locking problems.

Use simple sql statements to update your tables and you'll be a lot
better off.
Use ADP instead of MDB-- MDB was obsolete almost a decade ago.


-Aaron



Sylvain Lafontaine (fill the blanks, no spam please) wrote:
Because in this case that there will be only one or two external posts and
that they will accessing the post at the office with a low frequency
(something like one time per hour (see OP)), creating a virtual session with
VPC or Virtual Server (both free) and accessing this session via VNC (see
RealVNC) or with the Internet control (for Virtual Server) or any other
remote control (PC-Anywhere) would be cost effective because it's free
(excerpt in the case of PC-Anywhere) and can be used with their actual WinXP
installation.

I agree that Terminal Server will be a little faster but this will require
that they buy Win2003 Server.

There are also ISP sites that will offer you access to Terminal Services to
access your databases. This can be highly cost effective (one of my client
is using one at a cost of something like 50$ per month) because not only you
don't have to buy your own hardware but also you don't have to be worried
about making regular backups.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Brendan Reynolds" <brenreyn@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23gLHcfjCHHA.1012@xxxxxxxxxxxxxxxxxxxxxxx

In a previous post, Norman mentioned Terminal Services. I agree that this
is a potential solution that you might want to check out. This could solve
the problem for your remote users as well as your local users. Using
Terminal Services, remote users execute the application on your local
network. Only the screen display and keyboard/mouse input needs to be sent
across the WAN. All communication between the application and your
database happens on your LAN. Here's a link to the Terminal Services
documentation at TechNet ...

http://technet2.microsoft.com/windowsserver/en/technologies/featured/termserv/default.mspx

--
Brendan Reynolds
Access MVP

"Bruce Maston" <homebrew@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:4F073BA4-3D7A-40D7-BAE8-67EA7F640A3E@xxxxxxxxxxxxxxxx
Hi Norman,

Thank you for your reply. I will research the options you are suggesting
(learning curve for me here). I have a fixed IP address in my office,
and
from what you write, it seems I could improve performance at work (where
it
is most necessary) if I set up a server in the office. Machines in the
office would be client/server and would get the data rapidly. Meanwhile,
my
other machines off site would get the data at my present slow rate.

In that case (assuming I'm correct), would I need something like a Dell
small business server with SQL Server 2005 express?

"Norman Yuan" wrote:

Your performance issue is not with ODBC, rather, it is your (physical)
network connection. Usiing Access front-end to connection a back end
through
the Internet connection is definitely slow with currently affordable
network
connection. Just compare: a typical LAN speed is 100Mbp, a very
high-speed
cable connection to the Internet would be 100K - 1Mbp, 100 to 1000 times
difference. Unless you can get a network connection that fast enough and
compareable to the LAN speed (with big money), your Access front end to
the
remote backend via the Internet would be alway slow and not really
useful in
most cases.

You need to re-think the way to get data from remote server. For
example,
using web app/service to get data; or connect via terminal services, if
the
remote host provides such service; ...

"Bruce Maston" <homebrew@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:E8BF6231-397F-4A4F-81BA-61773F86D668@xxxxxxxxxxxxxxxx
I apologize if this is the wrong group. I have an Access 2000 app
running
at
three locations (my home, my office, and my partner's home). The
database
sits on an SQL Server at a "commercial" ISP site. The machines
connect to
the database via ODBC with the Jet database engine. I guess the lingo
is
that Access is the front end, and the SQL server is the back end.

Over the 5 years I've used this set-up, I've always been annoyed by
the
slow
response times. My database is extremely small, and it seems to me
that
for
the limited information I get out of it per query and the fact that a
query
is sent to the SQL Server by somebody about once per hour, it should
be
virually instantaneous.

Today I timed it as 15 seconds to make a chance in one record of one
from -1
to 0. The table has 230 records and 24 columns. Most columns are
either
yes/no or have only a date in them. In other words, it took 15
seconds
for
ADO to do a
.find and then !field=no then .update.

I'm wondering if there is any way to improve this. Is there a better
way
to
run my app rather than with ODBC? Would my problem improve if I had
my
own
server in my office (where only the machines at home had to get data
over
the
internet)? Could the problem be that the ISP's server is doing too
many
other things for other customers?

I'm a hobbiest, and I'm my own IT guy. (In my "real" job, I'm a
doctor.)
I
can't go to a main frame with Oracle, etc., but is there a "next
level"
out
there that I should consider moving to?

Thank you for any input.






.

Quantcast