J
Jan
I want to make a mdbfile where several users can use the same data at the
same time?
same time?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rick B
You will need to create a backedn database where all the data lives and
store it on a shared resource such as your LAN.
You will then need to create a front-end linked to the back-end. This
database file will contain all the forms, queries, reports, etc. Each user
will have a copy of it on their PC.
How far have you gotten in the process? What specifically is your question?
Rick B
store it on a shared resource such as your LAN.
You will then need to create a front-end linked to the back-end. This
database file will contain all the forms, queries, reports, etc. Each user
will have a copy of it on their PC.
How far have you gotten in the process? What specifically is your question?
Rick B
J
Jan
Ok , but then the users need access on the computer. I have made a simple
mdb.file , and i wan't my users to add data and run some reports
Rick B skrev:
mdb.file , and i wan't my users to add data and run some reports
Rick B skrev:
R
Rick B
Yes, they will need Access on their computers.
Jan said:Ok , but then the users need access on the computer. I have made a simple
mdb.file , and i wan't my users to add data and run some reports
Rick B skrev:
R
Rick Brandt
Jan said:Ok , but then the users need access on the computer. I have made a
simple mdb.file , and i wan't my users to add data and run some
reports
Yes, to use an MDB file all users need Access installed (either licensed or the
runtime), just as they would need Word to use a DOC file or Excel to use an XLS
file. I mean unless you want to write a front end to the data in VB or some
other programming language.
J
Jan
Many thank's to you Rick
Rick Brandt skrev:
Rick Brandt skrev:
Yes, to use an MDB file all users need Access installed (either licensed or the
runtime), just as they would need Word to use a DOC file or Excel to use an XLS
file. I mean unless you want to write a front end to the data in VB or some
other programming language.
T
Tom Wickerath
Joseph,
I have to take exception to the last sentence in your quote:
First of all, do you really think that God would entrust all of the critical data to a JET
database? Imagine the mayhem at the Pearly Gates if Saint Peter had to deal with a corrupted
database! Let's hope that God entrust such data to a more robust RDBMS, such as Oracle or SQL
Server.
But even for the less serious data processing needs, God would still have quick access to any
secured JET database. That's because, sadly, he called Cheryl Fischer home earlier this year.
Cheryl would likely crack any JET security in a big hurry.
In all seriousness, quotes that imply that Access security cannot be broken are misplaced. A
person new to Access might read such a quote, and end up believing that sensitive data is truly
secure in a (properly) secured JET database. Access security simply raises the bar. I don't
think it is right to give out misleading information that suggests otherwise. If you don't
believe me, just check out www.lostpassword.com
Tom
__________________________________
BTW you may want to implement user level security to control who has
what access.
I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793
Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can lock
everyone including God out.
Practice on some copies to make sure you know what you are doing.
Since you now have data on different machines and I am going to guess
that the data is not the same on each of those machines, you will need to
combine most, if not all of that data onto one copy of Access. This will be
complicated if the tables and data are not formatted exactly the same, For
example 123 in one data base may be text and it may be a number is a
different machine. One may use Three fields for a name FirstName, IM and
LastName and another may put it all in one field.
I suggest you start by deciding exactly how you want the final product
configured and then how you are going to get all that data into that one
database in the same format. Your final design may not be the same as any
of the existing designs.
Next you need to decide the split. What parts of the database will be
on the "server" and will be called the Back end database from now on and
which parts will be on each user's machine and will be called the front
ends. The back end should hold all data that is shared and may be changed
by the users. It should also contain all or most data that more than one
user will need access to and may be changed by you from time to time. Most
other data that does not change or that will only be used by that particular
user should be on the Back end databases on the users machines.
For example you may have all the sales made by a unit on the back end
along with the price list. The sales may been to be shared by everyone so
they all know what has been done or pending. The price list may not be a
field they will change, but you may need to change to assure everyone has
the same current price available.
Each individual machine may have something about your company like
addresses that does not change or even product descriptions etc. You may
want each user to be able to store personal information about customers like
their kids names or shared information about sports teams or you may want to
put this on the server so everyone will have this information.
This is an art form and a science to get this part of the planning
designed and will be an ongoing job and should include the users in the
planning.
Access works best if it does not need to move a lot of information over
the LAN which means static data is best kept on the front end databases.
Also kept on the front end machines will be most forms, reports queries etc.
This will allow the whole system to work faster and in some cases allow for
customization of some forms reports etc.
This may seem like a lot of work and off the point of the question you
were asking, but it is very important that this part of the job be done
first and right.
Next is the mechanics of setting up the back end on the server, dumping
in the data and putting the front end copies on each user's machines and
assuring that the links work. Access has a built in database splitter that
may make this part of the job (moving from a single database with all the
data and forms etc. to two databases a front end and a back end.) easier.
Look under the Tools menu for it.
You may also want to look into user level security to protect the
database and data before you finish.
I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793
Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can lock
everyone including God out.
Practice on some copies to make sure you know what you are doing.
Splitting a database can be a big job, but done right everyone will
thank you and wonder how they did their jobs without it.
Note: back ups become more important here. If you LAN does not support
automatic backups you should provide a method of backing up the data, even
if that means you do it manually.
A lot of information about splitting the database is available in the
help file and there is a wizard to help you through that part of the
process.
I have to take exception to the last sentence in your quote:
Access security is a great feature, but it is, by nature a complex
product with a very steep learning curve. Properly used it offers
very safe versatile protection and control. However a simple
mistake can lock everyone including God out.
First of all, do you really think that God would entrust all of the critical data to a JET
database? Imagine the mayhem at the Pearly Gates if Saint Peter had to deal with a corrupted
database! Let's hope that God entrust such data to a more robust RDBMS, such as Oracle or SQL
Server.
But even for the less serious data processing needs, God would still have quick access to any
secured JET database. That's because, sadly, he called Cheryl Fischer home earlier this year.
Cheryl would likely crack any JET security in a big hurry.
In all seriousness, quotes that imply that Access security cannot be broken are misplaced. A
person new to Access might read such a quote, and end up believing that sensitive data is truly
secure in a (properly) secured JET database. Access security simply raises the bar. I don't
think it is right to give out misleading information that suggests otherwise. If you don't
believe me, just check out www.lostpassword.com
Tom
__________________________________
Ok , but then the users need access on the computer. I have made a
simple mdb.file , and i wan't my users to add data and run some
reports
BTW you may want to implement user level security to control who has
what access.
I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793
Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can lock
everyone including God out.
Practice on some copies to make sure you know what you are doing.
Since you now have data on different machines and I am going to guess
that the data is not the same on each of those machines, you will need to
combine most, if not all of that data onto one copy of Access. This will be
complicated if the tables and data are not formatted exactly the same, For
example 123 in one data base may be text and it may be a number is a
different machine. One may use Three fields for a name FirstName, IM and
LastName and another may put it all in one field.
I suggest you start by deciding exactly how you want the final product
configured and then how you are going to get all that data into that one
database in the same format. Your final design may not be the same as any
of the existing designs.
Next you need to decide the split. What parts of the database will be
on the "server" and will be called the Back end database from now on and
which parts will be on each user's machine and will be called the front
ends. The back end should hold all data that is shared and may be changed
by the users. It should also contain all or most data that more than one
user will need access to and may be changed by you from time to time. Most
other data that does not change or that will only be used by that particular
user should be on the Back end databases on the users machines.
For example you may have all the sales made by a unit on the back end
along with the price list. The sales may been to be shared by everyone so
they all know what has been done or pending. The price list may not be a
field they will change, but you may need to change to assure everyone has
the same current price available.
Each individual machine may have something about your company like
addresses that does not change or even product descriptions etc. You may
want each user to be able to store personal information about customers like
their kids names or shared information about sports teams or you may want to
put this on the server so everyone will have this information.
This is an art form and a science to get this part of the planning
designed and will be an ongoing job and should include the users in the
planning.
Access works best if it does not need to move a lot of information over
the LAN which means static data is best kept on the front end databases.
Also kept on the front end machines will be most forms, reports queries etc.
This will allow the whole system to work faster and in some cases allow for
customization of some forms reports etc.
This may seem like a lot of work and off the point of the question you
were asking, but it is very important that this part of the job be done
first and right.
Next is the mechanics of setting up the back end on the server, dumping
in the data and putting the front end copies on each user's machines and
assuring that the links work. Access has a built in database splitter that
may make this part of the job (moving from a single database with all the
data and forms etc. to two databases a front end and a back end.) easier.
Look under the Tools menu for it.
You may also want to look into user level security to protect the
database and data before you finish.
I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793
Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can lock
everyone including God out.
Practice on some copies to make sure you know what you are doing.
Splitting a database can be a big job, but done right everyone will
thank you and wonder how they did their jobs without it.
Note: back ups become more important here. If you LAN does not support
automatic backups you should provide a method of backing up the data, even
if that means you do it manually.
A lot of information about splitting the database is available in the
help file and there is a wizard to help you through that part of the
process.
T
Tom Wickerath
You are correct. My intent was to tell the OP that if they are
No arguments here.
I agree that most reading could become completely locked out, if they are careless, and if they
must rely only on their own wit to get back in.
I question the statement "should always keep a non-secured copy". Of course, one should always
keep regular backups. A front-end doesn't necessarily need to be secured, unless it includes
sensitive data in local tables. What would be the point of keeping a non-secured copy of the
back-end? You'd have to either strip the security from a copy of your back-end every time you
made a back-up, or you'd need to duplicate your data entry efforts: once into the "real" secured
copy and then once again into the un-secured back-up copy.
It's good, but Windows security (Win. 2000 Pro & Server, Win. XP Pro & Server, etc.) is a lot
better. It's easier to simply deny RWCD privileges to those who have no business seeing the data
in the first place. It's more rare to have to protect data from legitimate users. First of all, a
legitimate user probably isn't going to be spending their time trying to gain access to data they
shouldn't see.
Happy New Year!
Tom
not careful they will be locked out and it will not be easy to
retrieve any data there, which is true.
No arguments here.
On the other hand let me also say that most of those reading
this will be 100% locked out if they are not careful and should
always keep a non-secured copy. I will also stand by the idea
that the user level security is a very good tool.
I agree that most reading could become completely locked out, if they are careless, and if they
must rely only on their own wit to get back in.
I question the statement "should always keep a non-secured copy". Of course, one should always
keep regular backups. A front-end doesn't necessarily need to be secured, unless it includes
sensitive data in local tables. What would be the point of keeping a non-secured copy of the
back-end? You'd have to either strip the security from a copy of your back-end every time you
made a back-up, or you'd need to duplicate your data entry efforts: once into the "real" secured
copy and then once again into the un-secured back-up copy.
I will also stand by the idea that the user level
security is a very good tool.
It's good, but Windows security (Win. 2000 Pro & Server, Win. XP Pro & Server, etc.) is a lot
better. It's easier to simply deny RWCD privileges to those who have no business seeing the data
in the first place. It's more rare to have to protect data from legitimate users. First of all, a
legitimate user probably isn't going to be spending their time trying to gain access to data they
shouldn't see.
Happy New Year!
Tom