|
Home > Archive > MS Access Multiuser > May 2005 > Multiusers use a Access App on network server
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Multiusers use a Access App on network server
|
|
|
| We plan to develop Access 2000 App, There are 25 users to run this App,
We will Split two MDB. one back end MDB put on the server, every user run a
front end MDB. Our questions is:
1. When all users log on the back end MDB, Is it very slow?
2. Can we put the SYSTEM.MDW on the server, join it from front end?
Thanks
Dou
| |
| Alex White MCDBA MCSE 2005-05-07, 7:24 am |
| You have to put the system.mdw in a shared location for it to work properly,
I recommend if you only have one database on the server put the system.mdw
file in the same directory as the BE database. You join the system.mdw file
with wrkadmin.exe that comes with ms office.
As for the performance question, always make sure the front-end database is
copied locally to each PC, as a rule of thumb I copy it to c:\documents and
settings\all users\desktop this means all users that log in to that pc have
it on their desktop.
As I am lazy (or don't like wasting time) I actually copy the front-end to
each desktop pc on each login, this means if I want to roll out a new front
end, copy the new version to specific location on the server and as each
user logs in they get the new version. This process is good whilst in
development and once you have a stable front-end stop copying the front-end
on each login.
If you need more help on the performance stuff, post back here with some
details of how large the BE database is and any processes or forms that run
when the database first starts up and I will try to help you some more.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"Dou" <telecom@szonline.net> wrote in message
news:Ob3aEUuUFHA.3636@TK2MSFTNGP14.phx.gbl...
> We plan to develop Access 2000 App, There are 25 users to run this App,
> We will Split two MDB. one back end MDB put on the server, every user run
> a
> front end MDB. Our questions is:
>
> 1. When all users log on the back end MDB, Is it very slow?
> 2. Can we put the SYSTEM.MDW on the server, join it from front end?
>
>
> Thanks
> Dou
>
>
>
>
| |
| Douglas J. Steele 2005-05-07, 7:24 am |
| Depends on how your application is designed. 25 users with a poorly designed
database may not work, even if it is split. You might want to take a look at
the Access Performance FAQ Tony Toews has at
http://www.granite.ab.ca/access/performancefaq.htm
Yes, your SYSTEM.MDW should be put on the server.
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)
"Dou" <telecom@szonline.net> wrote in message
news:Ob3aEUuUFHA.3636@TK2MSFTNGP14.phx.gbl...
> We plan to develop Access 2000 App, There are 25 users to run this App,
> We will Split two MDB. one back end MDB put on the server, every user run
> a
> front end MDB. Our questions is:
>
> 1. When all users log on the back end MDB, Is it very slow?
> 2. Can we put the SYSTEM.MDW on the server, join it from front end?
>
>
> Thanks
> Dou
>
>
>
>
| |
| Rick Brandt 2005-05-07, 9:24 am |
| "Dou" <telecom@szonline.net> wrote in message
news:Ob3aEUuUFHA.3636@TK2MSFTNGP14.phx.gbl...
> We plan to develop Access 2000 App, There are 25 users to run this App,
> We will Split two MDB. one back end MDB put on the server, every user run a
> front end MDB. Our questions is:
>
> 1. When all users log on the back end MDB, Is it very slow?
> 2. Can we put the SYSTEM.MDW on the server, join it from front end?
You don't say that you have applied User Level Security to this app. If not,
then every user can already use their own MDW file and you can forget about that
altogether. If you *have* applied ULS then your MDW file should NOT be named
"System.mdw" and you should place it on the server and give each user a shortcut
that specifies that MDW file as a command line argument. It is not recommended
that you make that the default workgroup file for your users as that will force
them to log in even when they are opening other files that do not have ULS
applied to them.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
| |
|
| This is a order processing program,BE database is less than 500MB (it will
more than 1GB after 3 years),
25 users log in this database at the same time.some pople input order data,
some pople read data and create invoice and other report. It opens main form
and linked to BE database 's tables when the database first starts up from
FE.
Is BE's MDB stable?
If BE database use SQL server, Is it better than MDB? If BE's MDB can meet
with our requirements,
I still want to use MDB, I think it's simple.
Thanks
Dou
"Alex White MCDBA MCSE" <alex@intralan.co.uk> 写入邮件
news:%230cq%23FwUFHA
.1148@tk2msftngp13.phx.gbl...
> You have to put the system.mdw in a shared location for it to work
properly,
> I recommend if you only have one database on the server put the system.mdw
> file in the same directory as the BE database. You join the system.mdw
file
> with wrkadmin.exe that comes with ms office.
>
> As for the performance question, always make sure the front-end database
is
> copied locally to each PC, as a rule of thumb I copy it to c:\documents
and
> settings\all users\desktop this means all users that log in to that pc
have
> it on their desktop.
>
> As I am lazy (or don't like wasting time) I actually copy the front-end to
> each desktop pc on each login, this means if I want to roll out a new
front
> end, copy the new version to specific location on the server and as each
> user logs in they get the new version. This process is good whilst in
> development and once you have a stable front-end stop copying the
front-end
> on each login.
>
> If you need more help on the performance stuff, post back here with some
> details of how large the BE database is and any processes or forms that
run
> when the database first starts up and I will try to help you some more.
>
> --
> Regards
>
> Alex White MCDBA MCSE
> http://www.intralan.co.uk
>
> "Dou" <telecom@szonline.net> wrote in message
> news:Ob3aEUuUFHA.3636@TK2MSFTNGP14.phx.gbl...
run[color=darkred]
>
>
| |
| Alex White MCDBA MCSE 2005-05-08, 7:23 am |
| Hi,
The limitation of an access mdb file is 2GB, so that needs to be considered,
in my view if I thought that I would go over that limitation within say 5
years then I would seriously look at the SQL backend solution, just to
replace an access BE mdb with SQL is not a major task, but to get the full
benefit of moving to SQL would require some serious work on your part, what
SQL brings to the party is much larger data stores and better reliability in
the high volume multi-user environment. So does your program re-link the
tables on every time the FE is started as this process can takes some time
and is not required to happen all the time? The FE (on the workstation) and
BE (on the server) using MDB is a well tested and reasonably reliable
solution and it performs pretty good for a non client-server solution. A
couple of other thoughts about performance, virus scanning on both the
server and the workstation, just for testing exclude from any on-access
scanning both the folder on the workstation and the folder on the server
that contain the FE and BE databases see if this makes a difference. If you
are re-linking the tables from the back-end on each time the FE is run there
are solutions to speed up that process. I don't think your problem is using
MDB type databases is the problem a I would say 'IF IT IS NOT BROKE DON'T
FIX IT'.
Do a compact and repair on all db's both FE and BE, test converting the FE
to MDE to see if that makes a difference (this removes all the human
readable code from the mdb, making the file much smaller in size), make sure
that the FE is located on the workstations and not run from the server.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"Dou" <telecom@szonline.net> wrote in message
news:%23D1Ryd3UFHA.3572@TK2MSFTNGP12.phx.gbl...
> This is a order processing program,BE database is less than 500MB (it will
> more than 1GB after 3 years),
> 25 users log in this database at the same time.some pople input order
> data,
> some pople read data and create invoice and other report. It opens main
> form
> and linked to BE database 's tables when the database first starts up from
> FE.
> Is BE's MDB stable?
>
> If BE database use SQL server, Is it better than MDB? If BE's MDB can
> meet
> with our requirements,
> I still want to use MDB, I think it's simple.
>
> Thanks
> Dou
>
>
> "Alex White MCDBA MCSE" <alex@intralan.co.uk> 写入邮件
> news:%230cq%23FwUFHA
.1148@tk2msftngp13.phx.gbl...
> properly,
> file
> is
> and
> have
> front
> front-end
> run
> run
>
>
| |
| david epsom dot com dot au 2005-05-08, 8:24 pm |
| And even if you *have* applied User Level Security, (see
Rick Brandt post in this thread), this is may not be the
best way to go about it.
That kind of ULS dates from a time when Windows did not
have any security at all. It's main advantage in a secured
Windows environment is that it shows the user name when
there are record locking conflicts.
That is an important point in some situations, but if
that feature is not useful, there are better ways.
Specifically, all permissions can be given to user groups,
not users: each Windows user can be given their own MDW file:
each users MDW should be stored in their Documents folder,
and referenced by a shortcut that specifies MSACCESS.EXE,
the application file, and the work group file: each Windows
user's MDW file should have the Admin user placed in the user
group with the appropriate permissions.
Administration of a system like that requires that for
every new user (created by the Windows Network administrator),
the administrator has to copy an MDW file with the appropriate
permissions into the users profile. That is a normal
scriptable task for any Network administrator.
Also, the MDW is not shared, so there is one fewer shared
files, with reduced locking and timing problems.
Compare to an older ULS system: each new user has to be
created in Windows and in Access: each new user has to
be given permissions in Windows and in Access: there is
an extra shared database that needs to be backed up: and
under some circumstances you can get locking and delay
problems with the workgroup database.
(david)
"Dou" <telecom@szonline.net> wrote in message
news:Ob3aEUuUFHA.3636@TK2MSFTNGP14.phx.gbl...
> We plan to develop Access 2000 App, There are 25 users to run this App,
> We will Split two MDB. one back end MDB put on the server, every user run
> a
> front end MDB. Our questions is:
>
> 1. When all users log on the back end MDB, Is it very slow?
> 2. Can we put the SYSTEM.MDW on the server, join it from front end?
>
>
> Thanks
> Dou
>
>
>
>
| |
|
| Our program re-link the tables every time when the FE is started.
Using the following code:
Set tdfLinked = dbsTemp.CreateTableDef("Orders")
tdfLinked.Connect = strConnect
dbsTemp.TableDefs.Delete tdfLinked.Name
tdfLinked.SourceTableName = "Orders"
dbsTemp.TableDefs.Append tdfLinked
here the strConnect=" ;DATABASE=\\HyServer
\OPSData.MDB"
How to to speed up this process?
Does the BE's MDB need to be compacted and repaired periodically?
I thought the BE database will move to SQL server in the future.
Or Now we use SQL at once.
Thanks a lot
Dou
"Alex White MCDBA MCSE" <alex@intralan.co.uk> 写入邮件
news:%23OCf3p6UFHA.1796@TK2MSFTNGP15.phx.gbl...
> Hi,
>
> The limitation of an access mdb file is 2GB, so that needs to be
considered,
> in my view if I thought that I would go over that limitation within say 5
> years then I would seriously look at the SQL backend solution, just to
> replace an access BE mdb with SQL is not a major task, but to get the full
> benefit of moving to SQL would require some serious work on your part,
what
> SQL brings to the party is much larger data stores and better reliability
in
> the high volume multi-user environment. So does your program re-link the
> tables on every time the FE is started as this process can takes some time
> and is not required to happen all the time? The FE (on the workstation)
and
> BE (on the server) using MDB is a well tested and reasonably reliable
> solution and it performs pretty good for a non client-server solution. A
> couple of other thoughts about performance, virus scanning on both the
> server and the workstation, just for testing exclude from any on-access
> scanning both the folder on the workstation and the folder on the server
> that contain the FE and BE databases see if this makes a difference. If
you
> are re-linking the tables from the back-end on each time the FE is run
there
> are solutions to speed up that process. I don't think your problem is
using
> MDB type databases is the problem a I would say 'IF IT IS NOT BROKE DON'T
> FIX IT'.
>
> Do a compact and repair on all db's both FE and BE, test converting the FE
> to MDE to see if that makes a difference (this removes all the human
> readable code from the mdb, making the file much smaller in size), make
sure
> that the FE is located on the workstations and not run from the server.
>
> --
> Regards
>
> Alex White MCDBA MCSE
> http://www.intralan.co.uk
>
> "Dou" <telecom@szonline.net> wrote in message
> news:%23D1Ryd3UFHA.3572@TK2MSFTNGP12.phx.gbl...
will[color=darkred]
from[color=darkred]
database[color=darkr
ed]
each[color=darkred]
some[color=darkred]
App,[color=darkred]
>
>
| |
| Alex White MCDBA MCSE 2005-05-09, 3:24 am |
| Just replied to someone else on the same thing, the 'trick' here is link
your first table, then open it in code, link all your other tables, then
close the opened table, that will speed things up.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"Dou" <telecom@szonline.net> wrote in message
news:uRcSRSEVFHA.2172@tk2msftngp13.phx.gbl...
> Our program re-link the tables every time when the FE is started.
> Using the following code:
>
> Set tdfLinked = dbsTemp.CreateTableDef("Orders")
> tdfLinked.Connect = strConnect
> dbsTemp.TableDefs.Delete tdfLinked.Name
> tdfLinked.SourceTableName = "Orders"
> dbsTemp.TableDefs.Append tdfLinked
>
> here the strConnect=" ;DATABASE=\\HyServer
\OPSData.MDB"
> How to to speed up this process?
>
> Does the BE's MDB need to be compacted and repaired periodically?
> I thought the BE database will move to SQL server in the future.
> Or Now we use SQL at once.
>
> Thanks a lot
> Dou
>
>
>
>
> "Alex White MCDBA MCSE" <alex@intralan.co.uk> 写入邮件
> news:%23OCf3p6UFHA.1796@TK2MSFTNGP15.phx.gbl...
> considered,
> what
> in
> and
> you
> there
> using
> sure
> will
> from
> database
> each
> some
> App,
>
>
|
|
|
|
|