Concise directions on separating database front end and back end??

[Guest]

I have a database application that is currently being used by 30-40 users.
It has been running successfully for the last 6 months, but I know from
reading the posts here that I should separate the front end from the back
end. I would appreciate it if someone would post CONCISE (easy to
understand) instructions on how this should best be accomplished. This is
the largest application I've worked with and the first time I've used one in
a multi-location environment. Currently, everyone is using the same mdb file
which resides on a network server. This server is physically located in the
same city as MOST of my users. However, there are a small number of users
who access the system remotely (over T1 lines?) from another city. The
response time for these users is quite slow. Will separating the front end
and back end help this situation? Thanks for your help.

 

[storrboy]

Start here:

http://allenbrowne.com/ser-01.html

 

[aaron.kempf]

you're a mother ****ing retard if you listen to the whole MDB split
front-end / back-end thign

just use Access Data Projects; get a decent dualie core server

and presto chango; you don't have any performance or admin problems

MDB is only used by lamers and retards

 

[aaron.kempf]

ADP can run over a VPN, a WAN, Wireless, or the Public Internet
without problems


MDB can't run over anything except LAN

MDB is for lamers and retards; don't use it for anything.
Learn SQL Server and use Access Data Projects.

anyone that is using MDB should be fired and then spit upon.