"Data Access Page" is not available in 2007, How to solve the internal network user's visit to the A

[Martin]

Dear all,

According to the previous discussion I posted in this group, I understand
that ACCESS 2007 do not have the "Data Access Page" functionality.

I want to know in ACCESS 2007, how can my collegues, using the internal
network, can visit and input data in my ACCESS document ?

( In ACCESS 2003, I use "Data Access Page" to let my collegues use my ACCESS
document. )

Thanks.

Martin

 

[Gina Whipp]

Martin,

The first thing that comes to mind is Sharepoint...

http://sharepoint2007.microsoft.com/Pages/Default.aspx

--
Gina Whipp
2010 Microsoft MVP (Access)

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

Dear all,

According to the previous discussion I posted in this group, I understand
that ACCESS 2007 do not have the "Data Access Page" functionality.

I want to know in ACCESS 2007, how can my collegues, using the internal
network, can visit and input data in my ACCESS document ?

( In ACCESS 2003, I use "Data Access Page" to let my collegues use my ACCESS
document. )

Thanks.

Martin

 

[John W. Vinson]

Dear all,

According to the previous discussion I posted in this group, I understand
that ACCESS 2007 do not have the "Data Access Page" functionality.

I want to know in ACCESS 2007, how can my collegues, using the internal
network, can visit and input data in my ACCESS document ?

Depends somewhat on the network. If it's a fast, stable LAN you can use a
split Access database: have the tables in an Access backend (or a SQL/Server
instance) and use an Access Frontend containing forms, reports, queries etc.
linked to the table; if it's not, proper SQL server setup will work or you can
use Terminal Server or Citrix.

 

[Larry Linson]

If by "internal network", you mean a LAN, you can split the data (back end)
and the user interface (front end), install the back end on the server
machine in your system, link the tables in the back end, give each user a
copy of the front end, and they will be able to read and update the tables
in the back end. One of Access' strong points has always been that it is
"multiuser" capable right out of the box.

If not all the users have Access, the Access 2007 runtime is freely
downloadable from Microsoft.

A carefully developed Access database, implemented in this way, will serve
30 -70 concurrent users. If you are on a WAN, rather than a LAN, this
solution will not work but you can use an SQL Server Express database as a
back end, and that will work nicely.

Larry Linson
Microsoft Office Access

 

[Steve]

In addition to the methods that have been suggested, you can also develop a
web front end to interact with the database using any number of languages
(.NET, PHP, ColdFusion, etc). Probably the easiest way to do this that I
have seen is using IronSpeed Designer, which will read the database and
generate a full-featured ASP.NET web site.

HTH

 

[Martin]

Hi,

You wrote:
"...you can split the data (back end)
and the user interface (front end), install the back end on the server
machine in your system, link the tables in the back end, give each user a
copy of the front end... "

What do you mean by "front end" here ? Here, for example what will be the
"front end" looks like in your mind ? ( it is the asp.net or it is the
hyperlink of the table ? please give me an example. Thanks)


Martin

 

[Martin]

Hi,

Wow! you mean use ".net" to create "front end" ??

Wow, it will make things very complicate.

Is there any simple method to create the "front end"? please give me an
example.

Thanks!


Martin

 

[John W. Vinson]

What do you mean by "front end" here ? Here, for example what will be the
"front end" looks like in your mind ? ( it is the asp.net or it is the
hyperlink of the table ? please give me an example. Thanks)

The "front end" in this context is an Access database (.mdb, .accdb, .mde or
..accde) database. It will typically not contain any tables itself, just links
to the shared backend tables. These might be in a .mdb/.accdb file or they
might be a SQL/Server or other client/server database. The frontend would also
contain all the needed Forms, Reports, Queries and code.

See http://www.granite.ab.ca/access/splitapp.htm and/or
http://allenbrowne.com/ser-01.html for a thorough discussion.

 

[Arvin Meyer [MVP]]

On a LAN, the simplest method is just to split your database and put all the
forms, reports, queries, and code in a front end. There's even a wizard to
do it. Each user will need a copy of Access or the runtime version, and
should have that copy on their workstation. Using .Net, is a thorough waste
of time, unless you have lots of users who are not local. In that case, you
probably would be better off with a SQL-Server database for the tables.

The back-end is the tables, and they run on your server, with each front-end
linked to it.

So other than an hour or 2 to split the database, and put a copy on each
workstation, you should be already done.

If you need a few outside users, or if you have users without Access
installed, you can use Terminal Services (RDS), with a variety of different
solutions.

The front-end is simply the database divided by the tables. Even without the
wizard it is simple to build (takes maybe 5 minutes). Simply make 2 copies
of the database file. Then on 1 copy delete all the tables. On the second
copy delete everything but the tables. Now use Get External data to link the
front end to the back-end that you've placed on the server, and copy the
front-end to each workstation.

 

[David W. Fenton]

If you are on a WAN, rather than a LAN, this
solution will not work but you can use an SQL Server Express
database as a back end, and that will work nicely.

Or host the app on Windows Terminal Server.

 

[David W. Fenton]

The back-end is the tables, and they run on your server, with each
front-end linked to it.

Not precisely correctly worded. The file with the back-end tables is
*stored* on your file server, but it's not "run" anywhere -- it has
no code in it to run, it's just a data file, and parts of it are
retrieved by each client PC as needed, as with any other file
stored on a file server.

 

[Arvin Meyer [MVP]]

In fact, only local files running as part of the server, and servers
themselves "run" on a server. All other file accesses are from a client
computer. That is probably common knowledge.