Access 2007 unusable over network

[Pete D.]

I was convinced she was having an affair, but turns out, she was buying me a
new corvette and couldn't decide the color.

 

[CMoya]

OK. So the "Track Name AutoCorrect Info" settings seems to have made a huge
huge difference. I will test some more and see.... but right now, the mdb's
seem usable and pretty responsive.

 

[Pete D.]

Thanks for the smile!! Hang in there, Duff

OK. So the "Track Name AutoCorrect Info" settings seems to have made a
huge huge difference. I will test some more and see.... but right now, the
mdb's seem usable and pretty responsive.

 

[David W. Fenton]

These aren't large or complicated mdb's. They're small and simple
files. No matter what size- a few k's- Access 2007 seems to be
doing something that 2000 & 2002 doesn't do. And the slowness
isn't just "slow"... it's unusable. It takes 2 minutes just for
Access to load the mdb. And every action or lookup can take up to
30 seconds. This doesn't happen with 2000 or 2002 which is
completely usable over the same connection.

Well, I, for one, don't invest time in solving problems that would
be eliminated by simply doing things right in the first place. In
your case, that means not even considering running an Access app (in
any version) across a VPN *unless* it's a wired connection with
bandwidth of at least 10Mbps. Anything less than that is just a
waste of time and resources.

Of course, if your back end is SQL Server, that's a different ball
game entirely. But if it's Jet, it's a waste of time and effort
trying to do it.

 

[David W. Fenton]

Looks like we'll have to go back to Excel for storing these small
sets of data... or we just ask Office 2007 users to 'remote' into
their desktops. It's a shame because this is exactly what Access
is intended and suited for.

No, it's not. It's not intended to be run across a VPN that's
running over a WAN connection.

 

[Arvin Meyer [MVP]]

Well, I, for one, don't invest time in solving problems that would
be eliminated by simply doing things right in the first place. In
your case, that means not even considering running an Access app (in
any version) across a VPN *unless* it's a wired connection with
bandwidth of at least 10Mbps. Anything less than that is just a
waste of time and resources.

I would add that any wireless connection is prone to corruption if the
connection is lost, as is any Internet connection that's not run on a VPN
through a Terminal Server or through a web server. The Internet is at best
99% reliable. That means you may experience corruption 2 or 3 times a year
if you run a straight VPN connection. With a Terminal Server, the chance is
near zero if done correctly, and close to that with a web server.

 

[Arvin Meyer [MVP]]

Looks like we'll have to go back to Excel for storing these small sets of
data... or we just ask Office 2007 users to 'remote' into their desktops.
It's a shame because this is exactly what Access is intended and suited
for.

Access was never suited for a WAN connection, no file server based RDMS is.

Remoting into their desktops, however is an excellent method since it is
using terminal services. That will be faster, more secure (if it's over a
VPN), and virtually corruption free, if the database is well designed.

 

[CMoya]

Yup. Confirmed. The "Track Name AutoCorrect Info" setting makes all the
difference in the world. Our mdb's are now usable over VPN. Everything is
responsive exactly like Ac2000 & 2002. Thanks everybody for the tips.

 

[CMoya]

Nobody but an idiot runs an Access app connected to Jet over a
non-LAN wired connection. That is, if you have less than 10Mbps of
bandwidth, you're just wasting your time.

These aren't Access "apps." They're simple tables with small sets of tabular
data that just happen to lend themselves to Access rather than Excel. When
we want to create "apps" we create them in .NET or ASPNET against SQL Server
back-ends. Using your own terminology, I'd say that only an idiot creates
"apps" in Access.

Well, sure, you could spend many days of programming time rewriting
your front end to use unbound forms and opening and closing
connections to the back end. But that's just a waste of time when
it's so much easier to provide accessibility across a WAN via
Windows Terminal Server.

In that case we wouldn't use Access. We'd use a real database server.

In any case, as I noted elsewhere turning off the "Track AutoCorrect Name
Changes" setting solved the problem. Access 07 runs just fine now against
our mdbs.

 

[Pete D.]

I think if you were to dig into your network you will find that everyone is
correct. Point is everyone is up and running, of course I could just be an
optimist. Now is the time to start a new thread, so...... how about that
time off for the Holidays!!

 

[David W. Fenton]

These aren't Access "apps." They're simple tables with small sets
of tabular data that just happen to lend themselves to Access
rather than Excel. When we want to create "apps" we create them in
.NET or ASPNET against SQL Server back-ends. Using your own
terminology, I'd say that only an idiot creates "apps" in Access.

Is there VBA in these MDBs? Are there forms or reports? If so, it's
an Access application.

And only an idiot would create an app in Access and not know it's an
app.

And only an idiot with such little knowledge would think to call
other people idiots for creating apps in Access -- it only betrays
massive ignorance by the person making the accusation of idiocy.

In that case we wouldn't use Access. We'd use a real database
server.

What will you build your application in?

In any case, as I noted elsewhere turning off the "Track
AutoCorrect Name Changes" setting solved the problem. Access 07
runs just fine now against our mdbs.

And only people who are completely ignorant of Access best practices
would ever roll out an Access application with Name AutoCorrect set
to ON. If you took the time to understand the tools you are using,
you never would have had this problem.

 

[CMoya]

Is there VBA in these MDBs? Are there forms or reports? If so, it's
an Access application.

And only an idiot would create an app in Access and not know it's an
app.

I didn't call you an idiot. You called me one. I was using your own
terminology. I have 10 years of experience coding against SQL Server and
Oracle from VB3/4/5/6 to .NET today. If you insist that an mdb with a couple
of tables and a couple dozen rows of data is an "app" more power to you. For
the upteenth time, the files I was talking about are small sets of data...
no reason to take 10 minutes to open a table or navigate through it.

And only an idiot with such little knowledge would think to call
other people idiots for creating apps in Access -- it only betrays
massive ignorance by the person making the accusation of idiocy.

I've created (or rather assisted in the development as part of a team)
fairly large apps in Access. I think it's pretty common consenses that real
development in either VB classic (back in the day) or WinForm .NET apps is
almost always the way to go. Most people realize this about half way through
their project... when they smack themselves on the head. I would never start
a *new* app in Access. But I understand that is your expertise and love.
That's cool too.

What will you build your application in?


And only people who are completely ignorant of Access best practices
would ever roll out an Access application with Name AutoCorrect set
to ON. If you took the time to understand the tools you are using,
you never would have had this problem.

This is true. Turning this one setting off made Access go from 10 minutes to
open a table to 3 seconds. My ignorance, yes. Unfortunately you had no clue
either. If *I* (me, myself) was an "expert" I'd already know that this one
setting compounds network usage exponentially and it would have been my
first suggestion. You had no clue. Only that it's a "best practice." Real
developers actually understand what those "best practices" mean underneath
it all.

 

[David W. Fenton]

[]

And only an idiot with such little knowledge would think to call
other people idiots for creating apps in Access -- it only
betrays massive ignorance by the person making the accusation of
idiocy.

I've created (or rather assisted in the development as part of a
team) fairly large apps in Access. I think it's pretty common
consenses that real development in either VB classic (back in the
day) or WinForm .NET apps is almost always the way to go.

It may be the consensus among the people you work with, but you'll
find near=100% disagreement in the Access newsgroups, which happens
to be where you're posting, in case you hadn't noticed.

Most people realize this about half way through
their project... when they smack themselves on the head. I would
never start a *new* app in Access. But I understand that is your
expertise and love. That's cool too.

You don't know much about Access application development, and that
shows from the fact that you didn't have Name AutoCorrect already
turned off. This is not a flaw in Access. It is a lack of experience
on your part that caused the problem in the first place.

You left his question completely unanswered, even though it's the
main point.

This is true. Turning this one setting off made Access go from 10
minutes to open a table to 3 seconds. My ignorance, yes.
Unfortunately you had no clue either.

I was assuming that nobody with any degree of expertise would leave
Name AutoCorrect on. I also assume that nobody who understands
Access would ever attempt to run an Access app across a connection
with inadequate bandwidth and reliability.

So sue me for not having expertise in resolving problems with WORST
PRACTICES in Access application development and deployment.

If *I* (me, myself) was an "expert" I'd already know that this one
setting compounds network usage exponentially and it would have
been my first suggestion. You had no clue. Only that it's a "best
practice." Real developers actually understand what those "best
practices" mean underneath it all.

I assumed you had more expertise than you do.

My mistake, though in retrospect, it's pretty obvious that I
shouldn't have made such an assumption.

 

[CMoya]

message
news:[email protected]...

[]

And only an idiot with such little knowledge would think to call
other people idiots for creating apps in Access -- it only
betrays massive ignorance by the person making the accusation of
idiocy.

I've created (or rather assisted in the development as part of a
team) fairly large apps in Access. I think it's pretty common
consenses that real development in either VB classic (back in the
day) or WinForm .NET apps is almost always the way to go.

It may be the consensus among the people you work with, but you'll
find near=100% disagreement in the Access newsgroups, which happens
to be where you're posting, in case you hadn't noticed.

Most people realize this about half way through
their project... when they smack themselves on the head. I would
never start a *new* app in Access. But I understand that is your
expertise and love. That's cool too.

You don't know much about Access application development, and that
shows from the fact that you didn't have Name AutoCorrect already
turned off. This is not a flaw in Access. It is a lack of experience
on your part that caused the problem in the first place.

The name AutoCorrect Feature didn't seem to cause a bottleneck in Access
2000 or 2002. As I can test right now on several machines... and they run
just fine on the same connection. It did/does in 2007 (not sure about 2003).
Yes, it is lack of experience on my part... and the assumption that a
setting that has been around for a long time wouldn't all of a sudden cause
a 10+ minute delay in low bandwidth situations.

That's why I posted in the newsgroup. And I got some bad advice and some
misleading advice... but also some very good advice which led me to the
right track. Guess which one was yours? If I followed your advice I would
have started a new 3 month VB.NET project a week ago (all for naught because
these *various* MDB's with various data structures don't lend themselves to
it). Good thing I've been doing programming for as long as I have and know
how to sift through info and advice.

You left his question completely unanswered, even though it's the
main point.

A real application? In my workplace we use VB.NET (some controls in C#) and
SQL Server for our internal apps and a combo of legacy ASP Classic and new
ASP.NET for our client web offerings.

But, THESE MDB's are not "apps." They are various sets of data (research)
built by people (and will continue to be built by people)... some
relational... some not. When they're done with their report or project, the
tables cease to be useful and only needed for historical filing purposes.
The schema changes from project to project and from client to client.
They're not created by programmers (like me) as Access first and foremost is
not exactly and wholely a development platform--- which is why these folks
do so well with it. Access is PERFECT for what they're doing with it.

These are files. Not "apps."

I was assuming that nobody with any degree of expertise would leave
Name AutoCorrect on. I also assume that nobody who understands
Access would ever attempt to run an Access app across a connection
with inadequate bandwidth and reliability.

So sue me for not having expertise in resolving problems with WORST
PRACTICES in Access application development and deployment.


I assumed you had more expertise than you do.

My mistake, though in retrospect, it's pretty obvious that I
shouldn't have made such an assumption.

If I had that much expertise in Access I would have answered my own question
and not posted in this newsgroup.

 

[David W. Fenton]

[]

PLONK.

 

[Tony Toews [MVP]]

These aren't Access "apps." They're simple tables with small sets of tabular
data that just happen to lend themselves to Access rather than Excel.

Very interesting. That difference would explain why some of us are
more skeptical than others. <smile> I can see that with only a
relatively few records that it could indeed be fairly fast even over a
slow connection.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

Nobody but an idiot

David

That comment is a bit strong for the newsgroups. Actually rather
rude.

Like everyone else initially I doubted CMoya's comments but after
their explanation everything makes a lot more sense.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

That comment is a bit strong for the newsgroups. Actually rather
rude.

\/\/hatever, Tony.

Like everyone else initially I doubted CMoya's comments but after
their explanation everything makes a lot more sense.

The comments reflect ignorance of the tool used, and, in fact,
complete disrespect for those who use the tools. That is, I may have
been insulting, but I wasn't the one to introduce insulting
comments.

 

[CMoya]

\/\/hatever, Tony.


The comments reflect ignorance of the tool used, and, in fact,
complete disrespect for those who use the tools. That is, I may have
been insulting, but I wasn't the one to introduce insulting
comments.

Yes you were. You were the first one to call anybody an idiot. I have great
respect for Access and its community.... as I used to do a lot development
work in it. I think it's an underused and underappreciated tool. In fact, I
see people all the time use Excel to do things that Access is way more
suited for. I happen to work in a place where the prior developers
established the RIGHT practices.... and they worked great until Access 2007
put a kink in it (solved by turning off that one setting that is ON by
default).

Your failure is in appreciating that not everybody uses Access as a
"development" platform... in fact, it's main purpose has always been for
END-USERS (not programmers) to use it *out-the-box*, which my company's
users have been doing for years.

 

[CMoya]

David

That comment is a bit strong for the newsgroups. Actually rather
rude.

Like everyone else initially I doubted CMoya's comments but after
their explanation everything makes a lot more sense.

Tony

Thank you. And thanks to tall the suggestions. I think it should be realized
that Access with small datasets (a couple of tables, several dozen rows)
works just great over VPN and low bandwidth situations and often is way more
suited for this than Excel in a network scenerio.... for researchers needing
to input data into tables whose schema changes from project to project and
from client to client.

Of course, the trick is in when realizing when a full blown "app" (SQL
Server + front-end) is more suitable as a solution. But for a lot of things
that many (many!) use Excel for, Access is way better at (our easily solved
glitched notwithstanding).