[AccessD] Ten most common tasks/problems in Access

Thanks, Jim. I'm adding all your items to my list. Much appreciated.

Arthur

On Sat, Oct 18, 2014 at 12:03 PM, Jim Dettman <jimdettman at verizon.net>
wrote:

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



-- 
Arthur