When using an Access front end to SQL Server or Oracle, Access is not a
consideration for the number of users, because the Access front end is being
used by ONE user (the front end is installed directly on the client).
Having that front end located on a server and called from the client makes
no difference. Each front end runs seperately from the others. You could
have 1,000 users if you want, all using an Access front end on a SQL Server
or Oracle database.
IMHO, the reason that many developers tend to shy away from Access has more
to do with the structure of code in the Access environment. Access is a
very RAD environment, which means that doing straight-forward things is very
easy, but doing anything complicated or outside the expectations of the
designers takes more time than it would in another language. There is a
point of diminishing returns with highly RAD environmnents in terms of
developer productivity.
If you are an experienced OO developer, you can probably create a front end
in VB.Net or C# is only 30% more time than in Access, so Access will appear
more performant at first. However, if you want many of the features of
..Net: easy interoperabilit y, Object orientation, Frameworks for updating the
client environments, clean mechanisms for security, encryption, XML, Web
Services, and other features, then Access will QUICKLY become a liability.
In addition, if you allow customers to access your database from Access,
they will be able to access the database from Excel and any ODBC connection
as well. Access pretty much requires full access to the table-level data
(as opposed to using a stored procedure interface). Speaking personally, in
large environmnets, this is simply not allowed for security and data control
purposes. Many IT security specialists would turn you down cold if you
suggested this option.
My advice: Create a front end in Access if you need to put together a front
end for simple use, for a small number of users, or for a proof of concept
in an internal environment (Intranet). Let your first interface be Access
to get something in front of the users, so that they can give you better
requirements. This would be an agile approach.
Then, following behind that, create a replacement interface in VB.Net or C#.
Bottom Line: If you want to create an interface that you will maintain and
keep running for more than a year, or you need real developer productivity
when using common features of modern systems, or you need to integrate the
application with other systems, then write your front end in VB.Net or C#.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Remco Groot Beumer" <no****@nospam. com> wrote in message
news:d3******** **@news6.zwoll1 .ov.home.nl...
Hello,
I'm trying to decide if the following situation would be workable:
Generate an MS Access Front End (which will run localy on client
computers),
which will link to a DBMS (SQL server or Oracle). As far as I know there
will be approx. 30 till 40 users max working on the database. I think
approx. 25 users will actually enter data (others will be mostly
reporting
and viewing).
I don't really know the network capacity.
Another possibilty would be to create this front end in a VB.NET
environment, using also a DBMS. This only will cost approx 30% more time
to
build (since we do not have a lot of components ready for use in this
environment).
I've red a lot of different issues on performance of an access database,
but
they mostly focus on the situation with an Access back end.
Can anybody give me some argumentation on this topic or some pros and cons
for the Access versusVB option.
Thanx ,
Remco GB
