Hi.
> After looking at Tony's BE page I've realized that I don't have it set up
as
> a FE and BE db.
Sorry. I wasn't very explanatory. What's important is the concept of a
centrally located database file that all front end copies of the database
can check on at startup to determine whether the front end has been updated
to a new version, then automatically replace the current copy of the front
end with the latest version. This process would save a lot of manual time
(yours!) needed for redistributing the front ends to the users every time
changes are made to the database. If you could convince your network admin
to create a network share to store the centrally located front end, then it
would save you considerable time over the life cycle of the database
application.
> I really don't know what I don't
> know. You know?
I know _exactly_ what you mean!
> I can't think of a situation where a user won't be at their own pc to
access
> the db. If they are at someone else's pc that also has the db files, they
> should be able to log on with their user ID and PW.
The problem arises when it comes time to change passwords, which should be
done periodically. If Joe changes his password while using the workgroup
information file that is stored on his own workstation, and he's later
working with Mike and then needs to log into the database from Mike's
computer, Joe will be using Mike's copy of the workgroup information file,
which _doesn't_ have Joe's new password.
If Joe can remember his old password, then he can still get in, but Joe has
to realize why his "current" password isn't working when he attempts to log
into the database on Mike's computer when the error message tells him that
he's using an invalid user name or password. Even if Joe realizes this, the
password in the workgroup information file on Mike's computer might be two
or three passwords ago, so Joe might not even remember what his old password
was.
There's no need to frustrate users unnecessarily like this. A centrally
located workgroup information file would be ideal for users who roam from
computer to computer during the work day.
> If you haven't noticed
> by now, this is my first distributed db with Access.
Everybody started somewhere. It will get faster and easier as you get more
practice.
HTH.
Gunny
See
http://www.QBuilt.com for all your database needs.
See
http://www.Access.QBuilt.com for Microsoft Access tips.
(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
"JMorrell" <(E-Mail Removed)> wrote in message
news:9FD46481-77FF-4214-BAE1-(E-Mail Removed)...
> After looking at Tony's BE page I've realized that I don't have it set up
as
> a FE and BE db. Which is ok, I guess. I really don't know what I don't
> know. You know?
>
> >If you want users to be able to open
> > the database from workstations other than their own, then this is _not_
a
> > good method of distribution.
>
> I can't think of a situation where a user won't be at their own pc to
access
> the db. If they are at someone else's pc that also has the db files, they
> should be able to log on with their user ID and PW. If you haven't
noticed
> by now, this is my first distributed db with Access.
>
> it does help.
> JMorrell
>
> "'69 Camaro" wrote:
>
> > Hi.
> >
> > > I think our system is different though. (our network admin is very
> > > tight when it comes to access to shared drives. only a select few,
and I
> > Do
> > > mean "few" are allowed access to any shared drive)
> >
> > Sounds like that precludes your users from accessing a centrally located
> > workgroup information file residing on the shared drive.
> >
> > > Our users will be emailed the front end (I think I've got the
> > nomenclature
> > > right) and it will sit on their pc.
> >
> > Why don't you take a look at Tony Toews' autofe utility for
automatically
> > distributing new front ends? You can check it out on this Web page:
> >
> > http://www.granite.ab.ca/access/autofe.htm
> >
> > > Will the user get bothe the .mdb AND the .mdw files?
> >
> > You'll need to E-mail the MDW file as well, since the users won't be
able to
> > access this file on the shared drive. If you want users to be able to
open
> > the database from workstations other than their own, then this is _not_
a
> > good method of distribution.
> >
> > HTH.
> >
> > Gunny
> >
> > See http://www.QBuilt.com for all your database needs.
> > See http://www.Access.QBuilt.com for Microsoft Access tips.
> >
> > (Please remove ZERO_SPAM from my reply E-mail address, so that a message
> > will be forwarded to me.)
> >
> >
> > "JMorrell" <(E-Mail Removed)> wrote in message
> > news:53D421F4-01A9-4500-BC61-(E-Mail Removed)...
> > > I guess that's all well and good for users that can connect to a
shared
> > > drive. I think our system is different though. (our network admin is
> > very
> > > tight when it comes to access to shared drives. only a select few,
and I
> > Do
> > > mean "few" are allowed access to any shared drive)
> > >
> > > Our users will be emailed the front end (I think I've got the
> > nomenclature
> > > right) and it will sit on their pc. The only "network traffic" will
be
> > back
> > > and forth to the SQL Server. I'm in the final stretch of the project
and
> > > it's time for a select few users to test drive. The dot in the file
name
> > is
> > > going away by the time they get hold of it. I only use it to
> > differentiate
> > > in my file system.
> > >
> > > Will the user get bothe the .mdb AND the .mdw files?
> > >
> > > tiaa,
> > > JMorrell
> > >
> > >
> > > "'69 Camaro" wrote:
> > >
> > > > Hi.
> > > >
> > > > > When I give the "fe" to a user, what will the path look like?
> > > >
> > > > Chances are, it won't look like your mapped network drive path.
Instead
> > of
> > > > a "hard coded" mapped drive letter, use a universal naming
convention
> > (UNC)
> > > > path, such as:
> > > >
> > > > "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
> > > > "\\ServerName\ShareName\Projects\Access\SAL\SAL_b1.2testDB.mdb"
/WRKGRP
> > > > "\\ServerName\ShareName\Projects\Access\SAL\SALSecurity.mdw"
> > > >
> > > > Then it won't matter that users map a different drive letter to that
> > server,
> > > > so your shortcut will work for all users, not just the ones that map
> > their
> > > > M:\ drive to that server. And the path to the Access executable
needs
> > to be
> > > > standard on all of the workstations. Otherwise, you'll have to
change
> > the
> > > > shortcut for any non-standard configurations to specifically point
to
> > the
> > > > Access executable.
> > > >
> > > > And if I were you, I'd get rid of that period in middle of the name
of
> > that
> > > > file, because there are a few built-in functions that fail when
there's
> > a
> > > > period in the file name prior to the file extension. It's difficult
to
> > pin
> > > > down the cause when these errors occur, so it's best to avoid them
> > > > completely by using a standard file naming convention.
> > > >
> > > > HTH.
> > > >
> > > > Gunny
> > > >
> > > > See http://www.QBuilt.com for all your database needs.
> > > > See http://www.Access.QBuilt.com for Microsoft Access tips.
> > > >
> > > > (Please remove ZERO_SPAM from my reply E-mail address, so that a
message
> > > > will be forwarded to me.)
> > > >
> > > >
> > > > "JMorrell" <(E-Mail Removed)> wrote in message
> > > > news:58E238D2-D0B8-4622-AEAD-(E-Mail Removed)...
> > > > > Using SQL Server to hold data, my secured mdb links to that data
and
> > all
> > > > is
> > > > > well. The shortcut path to the mdb reads:
> > > > >
> > > > > "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
> > > > > "M:\Projects\Access\SAL\SAL_b1.2testDB.mdb" /WRKGRP
> > > > > "M:\Projects\Access\SAL\SALSecurity.mdw"
> > > > >
> > > > > When I give the "fe" to a user, what will the path look like? I'm
> > having
> > > > a
> > > > > hard time visualizing the path.
> > > > >
> > > > > tia,
> > > > > --
> > > > > JMorrell
> > > >
> > > >
> > > >
> >
> >
> >