Given that most user access is via Citrix, we have Access licensees, a handy
SQL Server and a need to develop moderately active 10 - 100 concurrent user
databases, any +/- comments on using ADPs? We also have in place, the means
to distribute modified ADPs as the developers deem necessary.
Thanks to the group.
"FanJet"
news:4785247c$0$26893$4d3efbfe@news.sover.net...
> Given that most user access is via Citrix, we have Access licensees, a
> handy SQL Server and a need to develop moderately active 10 - 100
> concurrent user databases, any +/- comments on using ADPs? We also have in
> place, the means to distribute modified ADPs as the developers deem
> necessary.
>
> Thanks to the group.
I've worked on a number of Access client - server DB systems. I could see
no benefit of ADP over MDB, on the ADP that I worked on, and the Access team
at Microsoft is no longer touting ADPs over MDB as the "solution of choice
for client-server". I thought it took a bit longer to use ADO I/O, but that
ADPs were "serviceable". If I were going to develop a client-server
application with Access, I'd use MDB or ACCDB with ODBC linked tables in the
server DB.
On the other hand, depending on the type of activity and number of users, a
server DB may not be needed. If you expect the audience for your
application to grow to 100 or near, and most of those users will be
updating, as opposed to reading the information, client-server is likely
warranted. If you have some applications that are likely to never have a
user audience over 50 - 70 or less, and most of the users will be mostly
"read-only", and it's on a LAN (not a WAN) then a split Access - Jet may be
all you need.
There's a lot of discussion of multiuser vs. client-server in the
microsoft-sponsored newsgroup microsoft.public.access.multiuser, accessible
via an online interface (reachable via links from
http://office.microsoft.com or from the free news server news.microsoft.com)
and at MVP Tony Toews' website http:www.granite.ab.ca/accsmstr.htm. That
and other website resources are listed on my User Group SharePoint page,
http://mail.ntpcug.org/accesssig/default.aspx under Links.
Larry Linson
Microsoft Access MVP
"FanJet"
news:4785247c$0$26893$4d3efbfe@news.sover.net...
> Given that most user access is via Citrix, we have Access licensees, a
> handy SQL Server and a need to develop moderately active 10 - 100
> concurrent user databases, any +/- comments on using ADPs? We also have in
> place, the means to distribute modified ADPs as the developers deem
> necessary.
>
> Thanks to the group.
>
>
>
Since you're talking about using SQL server for the backend, there's no real
really a practical limit in terms of using MS access. in other word you're
only practical limits you'll encounter is your server system, the SQL server
engine itself, and other factors.
There are reports of corporate environments where there is in excess of 1000
users all signed in and using ms-access as a front end to sql server....
since your database engine is not a MS access, but SQL server, then you're
practical limits you're speaking of are really that of Microsoft SQL server
product, and has little if anything to do with the limits of MS access....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
One of a few nice things about the ADP (having worked on several) is
that the forms and Reports have an Input Parameters feature in the
properties sheet of the form/report where you can base the recordsource
of a form/report on a stored procedure on the sql server. Another
feature is a serverFilter property. There are a few other features
which the purpose was to have Access interact with the server directly.
For example, in the ADP the tables in the Tables window are all server
tables.
The big downside, however, of the ADP is that you have a continuous
connection to the server. The more ideal scenario would be to connect
to the server only as needed. This can be achieved with the mdb (and
also with .Net). However, if you use ODBC tables in the mdb, then you
are continuously connected to the server again. If having a continous
connection to the server is not an issue then I would go with the ADP.
But if you want more efficiency, I would go with the mdb and ADO (not
ODBC tables) or .Net.
The mdb is kind of like .Net because your can have disconnected
recordsets like with ADO.Net except that the records you would pull into
the mdb from the server get written to the disk rather than working in
virtual memory (like .Net). You are kind of between a rock and a hard
spot with Access and Sql server where the ADP reduces I/O but you have a
continuous connection, or the mdb can be used without a continous
connection but you increase I/O (.Net has solved both of these
problems).
Rich
*** Sent via Developersdex http://www.developersdex.com ***