Network performance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi
I have an 2000Access application which run in several network installations.
One of my customers claims that the application is very slow in his network.
On the server he has the table database (containing all his recorded data)
and the .mdw-file. On the client he has the object database (containing
forms, reports, code etc) and the Access 2000 runtime.
The path to the table database is very long with blanks and dots as you can
see below

G:\Kulturverksamhet\Konstmuseum\Offkonst\Konstregister backup
4.11\Konstverksbilder\ktables.mdb

I have two questions if someone can help me on this:
Does a long path slow down the performance?
Is Runtime slower than the “real†Access?
Best regards
 
A long path may slightly slow the initial connection to the data, but
shouldn't cause very much of a speed problem. It is simple to try a root
folder connection and see if it improves the speed.

I haven't noticed much, if any difference in speed of the runtime. The 2
versions are essentially the same. If anything, there is less overhead in
the runtime, so it should be very slightly faster.

Make sure that Track name AutoCorrect is off

Turn off sub datasheet Name property by setting [Auto] to [None]

Try making a persistent connection to the back-end. You can use a bound form
which is always open to accomplish this.

I use a dummy table with 1 record. Open a form during startup which is
hidden and bound to that table.

Have a look at Tony Toews performance faq to reduce some of the issues you
are seeing:

http://www.granite.ab.ca/access/performancefaq.htm
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access
 
A long path can cause slowdowns because of the OS security. This happens
because Access has to jump through a lot of hoops each time it goes to the BE
database file. This is especially true if usings UNCs instead of mapped
drives. Three things to try:

1. Do what Arvin said about making a persistent connection to the back-end.

2. Create a shorter path using another mapped drive.

3. For testing move the MDB file up nearer to the top level and see what
happens.
 
Thank's for your help gentlemen.
I have checked Track name AutoCorrect which is off in all the tables,
but where do I find the data sheet name property?
 
Access MBD is a piece of shit and you shouldn't use it for anything
anywhere.

MSDE is free-- the same price as MDB.
but data in MSDE has a FUTURE.
 
RE:
Try making a persistent connection to the back-end. You can use a bound
form
which is always open to accomplish this.



Access Data Projects do this out of the box; grow some balls Arvin and
learn TSQL



In the design view of the tables on the server, open the table's property
sheet and check the subdatasheet property. It should be set to:

[None]

any other setting should be set to [None] and saved.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

ORJAN said:
Thank's for your help gentlemen.
I have checked Track name AutoCorrect which is off in all the tables,
but where do I find the data sheet name property?
--
ORJAN


"Jerry Whittle" skrev:
 
learn TSQL

I have quite a bit of experience with T-SQL having used SQL-Server since
version 6.5 in 1997. I was a beta tester for SQL-Server for version 7.0.
Fortunately for my clients, I do know when to use an MDB or an ADP. My
preference is based soley on the requirements and not any pre-conceived
prejudice.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access
 
Arvin;

you are a dipshit and an extension racist and i hope you choke on that
MDB

sissy; don't even talk to me in that tone of voice

ADP is _VASTLY_ superior to MDB in every possible measure.

I've used SQL Server since 1997 also and I claim that you're an idiot;
and Microsoft is too drunk to DRIVE the future of Microsoft Access.

'based solely on requirements'

my requirements are for a STABLE, RELIABLE, PREDICTABLE query engine.

my requirements are for REAL INDEXING.

my requirements are to support 24x7 environments-- i can't kick
everyone out of the database in order to take a backup of my critical
data. i can't reboot a file-server just because Microsoft access is
throwing a tissy-fit.

And I need to support more than a single row

IF @@USERCOUNT > 1 OR @@ROWCOUNT > 1
BEGIN
PRINT 'YOU HAD BETTER USE SQL SERVER, MDB SISSIE'
END

-aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top