How do I close a previewed report after 60 seconds in MS Access?

How can I force a previewed report to CLOSE after some period of time?  A shared, networked application opens a report for preview when requested.  However if the user leaves it open on their desktop, it ties up a table and others cannot preview that report, until it is closed by the first user.

Is there a standard way to handle this multi-user issue?  Does the 'timer' function work on a report that has completed and is being previewed on the screen?  The timer seems to STOP.
Bill
bcreenAsked:
Who is Participating?
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Connect With a Mentor Database ArchitectCommented:
I would suggest finding out the *real* reason for this, instead of a Timer patch ...

mx
0
 
peter57rCommented:
I wouldn't expect a report to lock things up.
Are you using a split application with each user having their own copy of the front-end?
0
 
bcreenAuthor Commented:
I found the solution....  sorry I didn't search the "answers" before submitting the question.  The timer stuff works IF instead of Previewing the report, you simply open it in 'Report' mode, instead of Preview mode.

I will close or delete this question.  Thanks for your time!
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
"it ties up a table and others cannot preview that report,"
Is the design of the report (sorting/grouping) being modified on the fly when the report opens or any other design change?  Is the report opening any recordsets in code, which would not be a typical situation ?

And I would highly recommend you look into Peter's suggestion.

mx
0
 
Jeffrey CoachmanMIS LiasonCommented:
<No Points Wanted>

FWIW,

1. Timers user quite a bit of system resources.
2. Having a report close automatically may confuse and frustrate users.
3. You will still get the same error if the other users try to open the same report before the timer code kicks in.
4. In some cases the user may need to hold the report Open.  If you close it with a timer, they will only re-open it again, thus triggering the same issue...

For these reasons I am with MX on this...
Go with Pete's suggestion of investigating splitting the DB
(Fix the real problem and there will be no need for the inefficient timer code.)

"The timer stuff works IF instead of Previewing the report, you simply open it in 'Report' mode, instead of Preview mode."
Yes, but remember "Report View" will not generate a 100% faithful representation of the printout.
(No accurate graphics, no page numbering, no page breaks, ...etc)
Also when you add code to the Report, this code may not run in "Report View"

Finally, I will congratulate you on using the "Search" utility here, it is a great first resource.
You just may want to re-evaluate the appropriateness of the solution you found...

;-)

JeffCoachman



0
 
bcreenAuthor Commented:
Thanks to al contributors.  The  MDB is already 'split' into a data MDB and a design MDB.  The 'Report View' is actually even better than the Preview view for this particular report, as it is a quick on-screen reference as to what other users are using what other (MS Access) applications.  However, since it ALSO gets information from a non-Access third party accounting system, it needs to gather info for the report in TWO steps.  Step one gets Access-app usage, step two gets accounting system usage, from two different sources.

I chose to build a table with the two queries appending into it and the the report uses the table (or a  query based on the table...either way).

So are you guys implying that I could simply (?) use a union query, bypassing the table creation, and use the union query for the report source?  Would doing this, or something similar, solve the conflict with more than one user trying to view the report?  And would this be because the (union-) query would essentially create a virtual or 'temporary table' in each users memory which was unique for that user?

If someone can confirm, I will gladly split the points, as I will have been reminded of a very basic precept.

While we're at it, I considered building tables for this report that would be uniquely named, based on the userid, which I carry around in a public variable in everyone's front-end.... I see drawbacks with bloat and maintenance however.  Thoughts?

Thanks for sticking with me when I wanted to go with a quick fix!  :-)
0
 
Vee_ModCommented:
Stopping the auto-delete function per the Asker's request here:
http://www.experts-exchange.com/Q_26607552.html

Vee_Mod
Experts-Exchange Moderator
0
 
peter57rConnect With a Mentor Commented:
"I chose to build a table with the two queries appending into it and the the report uses the table (or a  query based on the table...either way)."

For a multi-user app, such user-specific data should ideally be in the front-end so as not to cause conflicts with other users.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.