[AccessD] Ten most common tasks/problems in Access

While we are at it, maybe we can come up with a top ten list of things that
need to be done in construction of a college campus? I mean really Art,
could you pick a wider subject perhaps? You could go down the table of
contents of any Access for Dummies book and immediately hit at least a dozen
and that is before you even get to anomalies like establish class modules
(but rumored to be very helpful); you'd eliminate macros, unless you are
from a culture that adores them; and now that you have mentioned integration
with other office products, you have practically opened up a new top ten
list.

I sometimes do mean to pick on you because you are smarter than me and I get
off on that kind of thing - but this is not one of those times, this is me
telling you I think that this is a way bigger list than you can usefully
condense it to.

Bill

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, October 18, 2014 5:50 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Ten most common tasks/problems in Access

I forgot an obvious task/problem that I have frequently needed in my
projects -- Office Integration -- using Access to create documents in Word
and Excel.

Arthur

On Sat, Oct 18, 2014 at 5:20 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> For a writing project I'm working on, I want to compile a list 
> (doesn't have to be precisely ten) of the most common tasks and 
> problems faced by Access developers. Perhaps I should explain my use 
> of these terms. First of all, I do not mean problems with Access itself.
>
> In the first category I mean things like writing form_load and 
> form_open code; creating combo-boxes whose source is a named query or 
> Select statement; writing code to open a second form (for example, 
> when a double-click on one form automatically opens a second, related 
> form); that sort of thing.
>
> In the second category, I mean such things like creating master-detail 
> forms; creating forms that will enable the user to perform complex 
> queries (parsing the query form and assembling the SQL from the values 
> chosen by the user). I suppose that into this category might go the 
> need to write complex processing code that has little or nothing to do 
> with forms; writing custom UDFs that don't exist in Access, passing 
> values from one form to another; creating nested reports.
>
> I don't want to rely solely on my own experience in assembling this list.
> So I'd like to reach out and take an informal poll here and see what 
> you think.
>
> --
> Arthur
>
>


--
Arthur
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com