[AccessD] Ten most common tasks/problems in Access

1 Creating popup forms to handle not in list events.

2. Building an interface for a many to many relationship (this is more of a
problem rather than a common task).

3. User security at form and record levels.

4. Saving and applying user preferences.

5. Saving and applying application settings.

6. Resource locking (keeping two users from doing the same thing at the same
time, like closing a G/L for the month).

7. I'd agree 100% on Office integration (Excel and Outlook mainly).

8. Creating a modern menu interface (ie. a side bar - there's no way to
control the main window well).

9. Producing what seems to be a standalone application (making it appear
that it's not Access driven).

Those are the top ones that bother me.   I'd also love to use more 3rd party
controls, but that is a problem with Access itself rather than one of
application design (#8 and #9 I guess are to really).

  That's all that springs to mind at the moment.

Jim.




 

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

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
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com