Re: Is this possible??
- From: Shanin <Shanin@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 4 Oct 2007 06:19:01 -0700
I understand Windows security but since I've not seen A2007 live, I'm
confused on how I would do some things. Here is what I have on this
database. The backend is on the server in it's own file. The backend
includes all of my tables, such as tblemployee, tbltraining, tblwage, etc.
Everyone has to have Windows permission to the backend to even use the
database, but everyone does not need to have access to tblwage which is
truthfully the only table everyone does not need to see. Currently how it
is, everyone can get to the backend via Windows Explorer and see the file is
there, but only certain people can actually login to it and see any of the
tables, and of course on the frontend, they are locked out of certain forms
and reports. If I go to A2007 how would I continue to keep information from
the tblwage from being seen since it sounds like you can't actually secure an
item and I can't lock everyone off the backend. Is it possible to break that
table off into it's own database, create a link to it so I can still have a
relationship and then set Windows security on just that table in it's
database?
I know this has gotten away from the original topic a bit, but thanks for
all the input.
"Pat Hartman (MVP)" wrote:
The OwnerAccess option is used with user level security - which is only.
available with the .mdb format. A2007 does not support ULS with the new
..accdb access.
Securing the folder is a Windows function and any one with access to the
folder will be able to use your front end to access the back end in that
folder. Other folks may be able to get to your front end if it is in a less
secure place but they will not be able to retrieve any data from the BE
because they don't have the correct network permissions.
"Shanin" <Shanin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:60BC4AE7-26B5-4E54-8B25-71CA4BE0FC83@xxxxxxxxxxxxxxxx
I guess I really need to sit down with the people and see what they really
want incorporated to see what we really need for our backside.
Unfortunatly
I have been using Access so I will be somewhat like you in taking a time
to
get used to the new look if we go that route.
Wouldn't it, if I secured the folder on the backside so only I could view
it, it lock everyone from being able to access the data from their
frontside,
or would it still work if the queries run with owner access? It seems I
tried that before, but it's been a while.
Thanks again.
"Pat Hartman (MVP)" wrote:
If you think your BE will eventually become SQL Server, it is best to
design
the application from the beginning using client/server concepts such as
forms bound to queries that include selection criteria to limit the data
retrieved by the form. Search here or the KB for articles on
client/server
optimization so you understand that to make use of server-side
processing,
you need to severely restrict the data retrieved.
Access 2007 does have some great new features and as long as you're not
an
existing Access user, you shouldn't have any trouble with it. Old-timers
like myself are struggling because we have to keep a foot in each version
and switching back and forth is a real pain.
As far as security goes, desktop applications are frequently secured by
using the security included in Windows that restricts access to server
shares. You would keep the back end database on the server where only
authorized people could get to it and the front ends on the local
machines.
What you loose with A2007 is the ability to secure objects in the
database
itself. However, you can use A2007 as your development/runtime
environment
but keep the application in the A2003 database format. That gives you
the
advantage of the new development features but it still allows you to
implement replication and user-level security.
"Shanin" <Shanin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:06389081-7CFC-431B-BA74-DBAD5EDDBCBF@xxxxxxxxxxxxxxxx
I was thinking SQL from the get go just due to the size it may become,
although I've never worked in that. You may not know the answer, but
is
it
hard to convert a backend Access table to SQL?
I also looked at Access 2007 and some of the features seem to be what
may
work for the frontend, such as the clicking on info in a report to open
a
form. We are thinking of upgrading our software anyway since it's been
a
while. Reading about the lack of security in A07, I think we'd
probably
want
to go to a backend SQL anyway to secure the tables since we wouldn't
want
every user to be able to access wage information of employees. Thanks
for
the info
"Pat Hartman (MVP)" wrote:
For starters, if you're going to do this, you would need to keep the
data
in
Access and from Access, produce any Word or Excel documents needed for
reporting. If the data comes to you from many places or people, you
can
use
Outlook Forms or Excel workbooks to gather the basic data and then
import
it
into Access. It is possible the much of the saving of documents can
be
dispensed with once the data is in a single place.
Access can handle millions of rows if each row is not very large. If
the
actual data is too large for Access or if you have too many concurrent
users
(over ~ 25), you can use SQL server or another RDBMS as the back end
while
still using Access as the front end.
It is seven years and three versions since A2K was released.
Microsoft
will
be discontinuing support for A2K in the not too distant future. It
might
be
time to upgrade to A2003 while copies are still available. Converting
to
A2007 is a huge change due to the complete recreation of the user
interface
and your company might not want to spring for the training involved
with
that.
"Shanin" <Shanin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:AC4B0474-1945-4091-A4CF-FF2507413A20@xxxxxxxxxxxxxxxx
I have a co-worker that would like me to build a database that
centralizes
a
huge amount of data and am wondering if Access would even be the
avenue
to
try and do this in. My thoughts initially are this would be a huge
undertaking and would probably lead to a swollen database and would
be
better
served by something other than Access.
What they want is this, a database that they can click on a client's
name,
where this would pull up a main screen which would show who worked
for
that
client, and several other options like med errors for this person,
the
person's budget, the person's plan and even being able to click on
the
staff
that work for the client and being able to view their trainings,
schedule,
etc. The main problem I see in all of this is all of this stuff is
in
numerous different applications. All HR/staff trainings, employee
information is in an Access Database I already built. Schedules are
in
a
FoxPro database which also is our timekeeping system. I have our HR
database
linked to that to pull schedules so that is not a problem. Budgets,
errors,
etc, these are under the clients folder on a server and are in Excel
and
Word, some are even still in Lotus. The part I would find hard is
the
budget
forms come from the State and have to be in that form and you have
to
hav
a
new on every month, sometimes more than one if an amendment is made
so
you
would have a hard time trying to link to something where the file
name
would
be constantly changing.
Without a total re-work of the agency on how things are reported, I
don't
see this as being possible and even then, I don't think Access would
be
the
best solution to store that much data.
Any thoughts?
- Prev by Date: Re: How to obtain logical combination for query result?
- Next by Date: Re: Date Table with Check Condition
- Previous by thread: RE: Could not update Currently Locked
- Next by thread: Re: Date Table with Check Condition
- Index(es):
Relevant Pages
|
|
