One very slow front end, not all.

[Guest]

Where I'm working we have an Access front end (XP file format / 2003
installation) connected to an MS SQL 2000 back end. This is done via an mdb
using ODBC rather than the FE being an ADP. Myself and another guy do any
developments (more he than I) and we then create an MDE and distribute it to
the users.

I am having a problem however in that all of a sudden, my front end has
slowed to a point that it is unusable. It WAS working fine but now it
doesn't and I am the only affected user. ~10 other users are all fine. I
have exactly the same mdb or mde as any other user may have.

I have also noticed that if I create a new mdb and link the same SQL tables
I have the same problem. If I create a new mdb and *import* some tables its
work fine.

So my problem is somewhere between my PC and the server or maybe even my
Access installation. FYI the server runs on a virtual server and all users
PC's access it through a designated hole in the firewall between the
production environment where our PC's live and the Test environment where the
SQL DB lives.

Anyone ever seen this behaviour before? or got any clues as to what could
be causing it? I've been programming Access/SQL for near on 10 years so
don't hold back.


Regs,
Mr. Smith

 

[strive4peace]

Hi Mr. Smith,


if you are experienced at SQL, you probably do as I ... code it in and
make it RowSources/RecordSources...

how long it is since you have done a compact/repair on the db?

her is someting else...

'~~~~~~~~~ Decompile ~~~~~~~~~

try decompiling the database

make an icon with this as its target:

"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\path\filename.mdb" /decompile

if your Access program is not located in the directory specified, make
the appropriate substitution

after you decompile, compile it if you have any code and then do
compact/repair

'~~~~~~~~~ ~~~~~~~~

you can also make a "generic" decompile icon where the next database you
open will be decomipled...

ie:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" /decompile


'~~~~~~~~~
Here's what I know about Decompiling:
http://www.rogersaccesslibrary.com/DecompilingDatabases.zip
The document is for Access 97, but it is still essentially correct for
Access 2000.

-- --Roger Carlson MS Access MVP www.rogersaccesslibrary.com
'~~~~~~~~~~

from (e-mail address removed)

* WORKING WITH LARGE PROGRAM DATABASES IN ACCESS 97
from the October 1998 issue of Access/Office/VB Advisor Magazine

http://web.archive.org/web/20030204023622/http://www.databasecreations.com/largedb.htm


'~~~~~~~~~~

Decompile or how to reduce Microsoft Access MDB/MDE size and decrease
start-up times
http://www.granite.ab.ca/access/decompile.htm

Unless there is a symptom I'd suggest no more than every month or so for
a front end under active development.

Tony
--
Tony Toews, Microsoft Access MVP
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

'~~~~~~~~~~

In addition to the other links you've been given, check out what Michael
Kaplan says at the following URL ...

http://www.trigeminal.com/usenet/usenet004.asp?1033

Always make a back up copy of your MDB or ADP before using the decompile
switch. It doesn't happen very often, but I have personally seen the
situation where a class module was no longer recognised as a class
module, but appeared to Access and VBA be a standard module, after a
decompile.

-- Brendan Reynolds

'~~~~~~~~~~
Trigeminal Software: The real deal on the /Decompile switch
http://www.trigeminal.com/usenet/usenet004.asp?1033

'~~~~~~~~~~

Warm Regards,
Crystal
*
have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*