Hi,

This client brought in this tech guy which copied and pasted our
data/backend MDB (front end is an MDE) onto a NAS drive from an XP
machine (am not sure what version of Windows he is now using - sorry).
Now one user logs into it and all is well. But another user logs in
and is not allowed to use it. He says an archive flag is being set
on the MDB file. So only one user at a time is now able to use the
application. It has been working flawlessly on a network for many
years until this guy decided to move the data to this NAS drive.

I have never seen or used one of these drives. And, I have never had
any issues with an archive setting (I assume that is one of the
advanced properties if you right-click on a file).

I just noticed he said he removed the archive flag (I assume he means
on the data mdb) and was immediately able to get in. But when another
user tried to get in the archive flag had been reset.

Sorry, reading backwords on his email: All their data from the shared
network drive is now accessible through a Samba Share (whatever that
is) from a NAS drive.

Any ideas?

I am guessing that the drive is locking the file while it is being
accessed. Its internal mechanisms / software may not allow multiple
access to a single file at the same time. Samba is quite old -
although frequently updated - and emulated a windows NT type domain
structure. This does not in itself guarantee that the underlying
system will allow multiple user access to the same file at the same
time even if they have permissions to read / write that file.

If you move the file to a share on a windows based machine, and place
it in a share (giving users permissions they need) and it still works
then your NAS is the cause of the problem. It would seem that since
that is the point you started from that the NAS is indeed the source
of the problem. Perhaps the NAS device will allow different file
systems (ext2 ext3 ext4, ntfs, etc...) and this might be a way around
the issue. Otherwise I would suggest that the device needs to be
changed for one that does allow that type of access. I have never seen
a specification for a NAS that states anything like that however, so
it might be trial and error to find one.

Another way around this might be to acquire one of those lightweight
ATOM based desktop boxes (ASUS make some really small and cheap ones,
even one with a battery built in like a laptop, I think its called and
EeePC B206). Set the device up on the network (headless - no monitor
keyboard or mouse) and simply open a share on it with the pre-
installed WinXP, and use that. Not perfect but could be a good
workaround.

Cheers

The Frog

On Tue, 30 Mar 2010 04:21:44 -0700 (PDT), The Frog
<mr.frog.to.you (AT) googlemail (DOT) com> wrote:


So Froggy :-) Are you saying that the problem is theirs and not ours?
I think so!! I am not sure if we should even be supporting client
that has their data on something that can be detached.

-paulw

"PW" <emailaddyinsig (AT) ifIremember (DOT) com> wrote

Samba is software to emulate a Windows file share "SMB" on a Unix or Linux
computer. I experimented with it a few years back; had the same problems.
After some research decided not to try it in production. The consensus then,
was that Jet/Access uses low level undocumented calls to SMB that are not
duplicated in Samba. Even if you fix the share problem, you may increase the
likelihood of file corruption.

On Tue, 30 Mar 2010 16:06:39 -0500, "paii, Ron" <none (AT) no (DOT) com> wrote:

Very helpful Ron! Thanks!

-paulw

Hi PW

Yes I am saying that the issue is probably with their hardware -
specifically the NAS device. I hadn't thought about it at the SMB
level but since Ron has mentioned it that would also make a lot of
sense. Samba is not a perfect implementation of SMB. It functions for
mos things, but not everything. I still think your easiest test is to
just shift the BE to a proper windows share, see if it works there,
shift it back and see that it doesnt work and hey presto - its got to
be the NAS. Twenty minutes work and you have your answer definitively.

Cheers

The Frog

On Wed, 31 Mar 2010 00:27:59 -0700 (PDT), The Frog
<mr.frog.to.you (AT) googlemail (DOT) com> wrote:


Thanks!! The guy gave in thanks to your help and Ron's and went back
to putting the data on a Windows box and is very happy now. I think
we both learned a lot thanks to you and Ron.

Thank you both very much!

-paul

On Mar 29, 11:38*pm, PW <emailaddyin... (AT) ifIremember (DOT) com> wrote:
As someone who has used a Samba share on linux and different NAS
drives successfully with Access 97 through Access 2003, I offer the
following thoughts.

The ones and zeroes used to store a file on a NAS or on a Samba share
are exactly the same as the ones and zeroes stored on a Windows
Server. So the issue for Samba is usually the unix-style permissions
of linux (i.e., user, group, world). I'll suggest that anyone without
a fairly strong grasp of networking should cave in to the fear
mongering and abandon Samba :-).

Samba is capable of supporting Windows authentication, it's own
authentication (IMO, a hassle), or LDAP authentication tied in to
Active Directory. It doesn't hurt to have an LMHOSTS file pointed to
the linux server. When Samba is supporting Windows authentication,
the connections count against the number of users licensed to the
Windows Server machine doing the authentication. One way to use
Samba's authentication or LDAP with Active Directory effectively (BTW,
no license limit) would be to have least two linux servers running a
separate trusted domain. The NAS drives I have interfaced with have
been much slower than a straight Samba setup, but were also
indistinguishable from a drive on a Windows Server machine, except
that everyone noticed that file and database access were suddenly many
times faster once Samba was put in place. The Samba setup had no
trouble at all handling Access' .ldb file properly.

If you go to a Samba setup, you are basically on your own as far as
Microsoft support is concerned, but I found Samba to be faster and
more reliable than a Windows Server is. The company I work at
abandoned linux for reasons unrelated to performance or quality.

A deliberate move by Microsoft to cobble Samba by extending the way
SMB works would probably not be a good idea for Microsoft. They've
done that with other products in the past, but at a time when
Microsoft needs our trust more than ever to pursue their plans, it
would not be good idea to remind everyone of how evil they've been in
the past. Such a move would not cause me to abandon Microsoft
technologies, but it would not give me much cause to recommend them
either. Samba on linux has enough to offer that if a reasonably
knowledgeable network administrator is available, it should be
tested. I might set up Samba again to see how well it works.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com

Can we trust Microsoft? I think we all know the answer to that. --
Microsoft PDC05 session host

On Wed, 31 Mar 2010 08:47:40 -0700 (PDT), "James A. Fortune"
<CDMAPoster (AT) FortuneJames (DOT) com> wrote:


Thanks James. I don't think the guy that decided to put our app data
on the NAS could have been any way qualified to have done so. This
seems like complex stuff!

-paulw

On Mar 31, 2:58*pm, PW <emailaddyin... (AT) ifIremember (DOT) com> wrote:
Fair enough. It can get complicated. Keep Samba in mind if your
network administrator situation changes or perhaps get a NAS that is
already set up to be 100% compatible with Windows.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com