Access Frontend to an SQL Server backend

  • Thread starter Thread starter jay
  • Start date Start date
J

jay

Why would someone choose to go this direction. After searching the web it
seems that are multi-user simultaneous access problems with this setup. How
do we convince clients to use the more advanced languages and platforms.

This may be the scenerio with a new project in my near future.

Thanks for any input on this issue
 
jay said:
Why would someone choose to go this direction. After searching the web it
seems that are multi-user simultaneous access problems with this setup.
Click to expand...

No... there aren't. There can be multi-user problems when using Access against
a Jet back end. I know of no difficulties or problems when using a SQL Server
(or any other server-based) back end
How
do we convince clients to use the more advanced languages and platforms.
Click to expand...

Lie to them?
 
I have never seen any article anywhere that would state that using ms-access
as front end to sql server would be a source of problems.


Do you have any link that states otherwise?

SQL server when setup correctly is VERY reliable. With a good server, you
can easily connect 100's of ms-access users without a problem at all.
 
And if you add a middle tier of business objects you can scale to thousands
of users,
since each user no longer gets a direct connection to the SQL Server and a
connection pool is set up.
 
Well, likely anything... a poorly designed application will work poorly.

That front end to sql server can be VB, c++ or ms-access.

if a poor job is done..then the results will be poor.

Really, there is no difference in performance if you use VB, or c++ or
ms-access to sql server.

The only problem here is poor developers. Those posters obviously are not
experienced with ms-access at all. Further, the responses are full of
errors.

To quote:
(hopefully a real
Click to expand...
guru can answer this for sure) is that even with linked
tables not all the database processing takes place at the
server. If the tables are large or your queries are
complex, this can clog your network and bring things to a
grinding halt.

Actually, in most cases all the processing DOES occur on the server. Even
when you use a bound form, and send it a "where" clause to restrict the form
load to the one record sql server does a very good job and only sends down
the write ONE record. I shall assume that you NEVER wrote an application
where you just open a form attached to a table..right? That is the kind of
terrible design thing that you should NEVER do in ms-access (ie: you always
open a form with a where clause to the one record you need).

For any type of query that needs multiple tables..then any fool would create
a view on the sql server side..and link to that. (this applies only to
ms-access and odbc). If you are using a ms-access project...then all queries
are created and run on the sql server by default anyway. In fact, with a ADP
project..there is NO local tables, or not even a local database engine...it
all occurs on the server side.

So, no..any problems of performance is just one of developers not knowing
what they are doing...or simply lack of experience.

Without question, if you use sql server...you do need to know how to use sql
server, and have decent design skills to make your application function
correctly.

However, there is NO special shortcomings or problems that is distinct to
ms-access as a front end. The only shortcommings are that of the
developers...
 
Back
Top