[AccessD] Ac2013 running out of resources

[Bill Benson]

That was exactly the comic relief I needed!

I just finished rewriting the database to record which reports will be run,
then update each report with a spooled date flag, and after a certain
report milestone, ask the user to shut down the database, and at startup I
test if there are reports without a spooled date, prompt the user to
continue from where spooling left off.

I am sure my users will appreciate this "take a break from doing your
reports" feature.

If I can get the user to agree to a companion reporting database that I can
automate, export data to, have it run reports and shut down, then this
stilted,  interrupted reporting session can be averted... until then they
have to live with the work around.

Thanks all. Learned nothing through this but distrust of Access2013, but I
can always count on being humbled every time I hitch my star to MS Access.
On Jun 6, 2015 5:53 PM, "Edward Zuris" <edzedz at comcast.net> wrote:

>
> "I think this is a situation where Access, not the developer, is at fault."
>
> That could be true.
>
> When I was brown-badge at MSFT we were told to call anomalies features.
>
> I spend a lot of time working around features.
>
> Maybe the report-writer has a memory leak feature.
>
>
> -----Original Message-----
> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> Bill Benson
> Sent: Saturday, June 06, 2015 3:15 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Ac2013 running out of resources
>
> Edward,
>
> I switched the report to not run ANY SQL during the report creation,  ie,
> to run the reports with no where clauses and based on very simple tables
> that were created along the way from a make table query. Rehardless,  the
> out of resources issue persisted.
>
> My vba is, I believe, pretty basic, no pun intended.  I don't see much that
> could or should be simplified, but what minor changes were proposed, I
> followed - those improvements didn't help.
>
> My queries are hardly complex, in my view, having written far more complex
> queries in the past. And again, I forsook them to run reports against
> tables instead. The one thing I did not try was creating a few hundred temp
> queries in the database and running a single report with revolving
> recordsource - instead of altering the SQL in a single querydef. However,
> since I got no improvement using tables instead, I cannot imagine anything
> to be gained from this new strategy.
>
> As for system tweaks, I have not considered memory management because I
> could never control this for all potential users of the software.
>
> I think some of this guidance is appropriate for other situations, I just
> don't see it as all that relating to my problem. Maybe I am myopic and
> stubborn and can't see a problem that is right under my own nose, or one
> which I am too close to, to see. In any case I appreciate the concern and
> devotion of yourself and others on this List, but I think this is a
> situation where Access, not the developer, is at fault.
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>