From: QB on
Jerry,

Can I bother you with one more question/request.

I have to try and explain this to my boss. Any chance you could explain in
plain English in 2-3 sentences my a NAS device is not well suited for an
access back-end?

I tried googling 'MS access NAS' but can't find much, little alone an
explanation.

Thank you for all our help,

QB





"Jerry Whittle" wrote:

> The first thing that I would check would be the same if the file was out on a
> server: do all users have read, write, create, and delete privileges to both
> the file and the entire folder that the database file is in?
>
> Next I would take the database file out to a server location AND also your
> hard drive. Compare how it works in the three different locations. BTW: you
> can open it up twice on your PC to test it when the file is on the hard drive.
>
> If you did all the above and it's still slow on the NAS, then I'd grovel for
> a spot on the server.
> --
> Jerry Whittle, Microsoft Access MVP
> Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
>
>
> "QB" wrote:
>
> > Any best practices, or means to do any form of optimization for this
> > application on the NAS? Or am I better to scrap the idea completly and
> > request access to a standard file server (may not be possible but I can ask)?
> >
> > QB
> >
> >
> >
> >
> > "Jerry Whittle" wrote:
> >
> > > For the most part a NAS drive is like putting files on another computer
> > > peer-to-peer. You won't get the throughput like putting the files out on a
> > > server.
> > > --
> > > Jerry Whittle, Microsoft Access MVP
> > > Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
> > >
> > >
> > > "QB" wrote:
> > >
> > > > I have a split 2003 mdb on a NAS and for some reason when a second user, or
> > > > more, connect there is a drastic performance hit. The db becomes very slow
> > > > to respond to any user actions...
> > > >
> > > > Anyone have any ideas as to why?
> > > >
> > > > QB
From: Tony Toews [MVP] on
QB <QB(a)discussions.microsoft.com> wrote:

>I have a split 2003 mdb on a NAS and for some reason when a second user, or
>more, connect there is a drastic performance hit. The db becomes very slow
>to respond to any user actions...

An NAS can certainly be troublesome with respect to odd problems and
corruption. However this sounds much more like the standard
performance problem.

The three most common performance problems in Access 2000 or newer
are:
- LDB locking which a persistent recordset connection or an always
open bound form corrects (multiple users)
- sub datasheet Name property set to [Auto] should be [None]
- Track name AutoCorrect should be off

If the problem is for everyone when starting up the MDB then it likely
needs a decompile.

For more information on these, less likely causes, other tips and
links to MS KB articles visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: QB on
David,

How can I identify whether this is a culprit or not in my case?

QB





"David W. Fenton" wrote:

> =?Utf-8?B?UUI=?= <QB(a)discussions.microsoft.com> wrote in
> news:0DDB0F10-3009-4138-B6E4-57C343B1F55B(a)microsoft.com:
>
> > Any best practices, or means to do any form of optimization for
> > this application on the NAS? Or am I better to scrap the idea
> > completly and request access to a standard file server (may not be
> > possible but I can ask)?
>
> Most NAS drives are not using NTFS as the file system, so there
> could be issues with Jet interacting with a foreign file system
> (most often via Samba).
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
> .
>
From: David W. Fenton on
=?Utf-8?B?UUI=?= <QB(a)discussions.microsoft.com> wrote in
news:B25A21D5-B7E9-49F9-8CCD-827966E89F37(a)microsoft.com:

> "David W. Fenton" wrote:
>
>> =?Utf-8?B?UUI=?= <QB(a)discussions.microsoft.com> wrote in
>> news:0DDB0F10-3009-4138-B6E4-57C343B1F55B(a)microsoft.com:
>>
>> > Any best practices, or means to do any form of optimization for
>> > this application on the NAS? Or am I better to scrap the idea
>> > completly and request access to a standard file server (may not
>> > be possible but I can ask)?
>>
>> Most NAS drives are not using NTFS as the file system, so there
>> could be issues with Jet interacting with a foreign file system
>> (most often via Samba).
>
> How can I identify whether this is a culprit or not in my case?

Move the file to a machine running an NTFS file system and see if it
fixes the problem.

So far as I'm aware, most of the NAS devices available out there are
running an embedded Linux with a Samba server. And that means the
drives are not NTFS (though it is possible for Linux to read/write
NTFS with 3rd-party drivers; I have a client using it and it hasn't
caused any issues).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: De Jager on

"QB" <QB(a)discussions.microsoft.com> wrote in message
news:45E2F26F-A834-4404-91F4-C1A581CFA0D8(a)microsoft.com...
>I have a split 2003 mdb on a NAS and for some reason when a second user, or
> more, connect there is a drastic performance hit. The db becomes very
> slow
> to respond to any user actions...
>
> Anyone have any ideas as to why?
>
> QB