run report outside access ???

[Pat Coleman]

We have a report that our truck drivers need to run each morning.

It shows them what orders are on their truck.

I have a short cut for the report on the desktop but when the click it , MS
access has to open up, then the database in the reports section, then thr
report.

The problem is that they can see all these other reports that I dont want
visable in the warehouse screen.

Is there any way that the driver can click on a shorcut and the report just
opens up for him to print and nothing else open on the screen.

 

[Guest]

Firstly, if you haven't done so already, split the database into separate
front and back ends, the former containing forms, reports, queries etc, the
latter just the tables. The front end will contain links to the tables. The
built in database splitter wizard will do this for you , creating a back end
..mdb file with a suffix _be.

You can now create another blank front end file with a different name, e.g.
OrdersReport.mdb. In this create links to the tables used by the report in
the back end via the File | Get External data | Link menu item. Copy the
report and any queries used by it from the current file to the new front end.

In the new front end create a macro named AutoExec which opens the report in
print preview using the OpenReport action.

Put a copy of the new front end on the relevant machine(s) and create a
shortcut to it on the desktop(s). If the back end is in a share on a server
you might need to refresh the links to the back end tables if you've not used
universal addressing to map to the shared folder. This is done by the built
in Linked Table Manager.

When the shortcut is clicked the new front end should open and automatically
open the report. As there will be no other reports in this front end file
the users will only be able to see the one report even if they should open
the database window at the reports page.

Ideally you should implement group and user level security so that access to
objects is controlled on the basis of groups of users. This would give much
greater control over access to the data, but requires a fair amount more work
to be done to set it up. You'll find a detailed explanation of how to
implement security at:


http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp


Ken Sheridan
Stafford, England

 

[Pat Coleman]

Thanks a lot

I'll get working on it.

Pat

Firstly, if you haven't done so already, split the database into separate
front and back ends, the former containing forms, reports, queries etc,
the
latter just the tables. The front end will contain links to the tables.
The
built in database splitter wizard will do this for you , creating a back
end
.mdb file with a suffix _be.

You can now create another blank front end file with a different name,
e.g.
OrdersReport.mdb. In this create links to the tables used by the report
in
the back end via the File | Get External data | Link menu item. Copy the
report and any queries used by it from the current file to the new front
end.

In the new front end create a macro named AutoExec which opens the report
in
print preview using the OpenReport action.

Put a copy of the new front end on the relevant machine(s) and create a
shortcut to it on the desktop(s). If the back end is in a share on a
server
you might need to refresh the links to the back end tables if you've not
used
universal addressing to map to the shared folder. This is done by the
built
in Linked Table Manager.

When the shortcut is clicked the new front end should open and
automatically
open the report. As there will be no other reports in this front end file
the users will only be able to see the one report even if they should open
the database window at the reports page.

Ideally you should implement group and user level security so that access
to
objects is controlled on the basis of groups of users. This would give
much
greater control over access to the data, but requires a fair amount more
work
to be done to set it up. You'll find a detailed explanation of how to
implement security at:


http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp


Ken Sheridan
Stafford, England