Jim Dettman
jimdettman at verizon.net
Wed Aug 20 12:34:37 CDT 2014
Steve, It's an issue for several reasons. First, it's not at all obvious to a user that there are separate forms, who instead sees the interface as a single form. They expect it to work as a complete unit. So the first problem you get is the expectation to be able to cancel/undo and have everything disappear. That doesn't happen. Navigation is also not intuitive; I tab / back tab for moving through the main form, but when I hit a sub form, I need to use Ctrl/Tab to move into it. Second problem is the main form events Before Update, After Update, and After Insert are all fired. That makes doing main level logic difficult. For example, if I want to ensure that a order is saved with at least one line item to be considered valid, I can't easily do that. How do I tell when their really moving off a main record vs just jumping into a sub form? There's also the processing delay when I move off the main form into a sub form, which is un-expected to the user. Any errors in the main form record also need to be handled. Nothing more confusing to a user than moving into a sub form, and getting a bunch of errors. The question always is "Why is it doing that now? I'm not finished yet." Third thing is that I've actually committed the record to the DB. Let's take a sequential invoice number; I've either had to use one and can't give it back, or I had to save a record without assigning one. Either of those is not attractive. And if a user decides they want to cancel, I now need to go back and delete the main record. In general, it usually means you resort to temp tables and moving data around in order to get a good interface, but that has issues to. I never realized how much of a chore main /sub form combinations in Access were until I used VFP. In VFP, you can elect to use several different buffering modes and one of those is to buffer things until you explicitly commit, which makes parent / child forms very easy to do and quite painless. Access came close to that when they finally allowed you to bind a record set in code to a form (meaning you could use transactions), but it doesn't quite work the way it should. And of course you could go the fully unbound route, but if your doing that, then why use Access at all. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Wednesday, August 20, 2014 12:24 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Most common problems/situations That's interesting, Jim. I have never thought of the "automatic save of a main record when you move into a sub form control" as a problem. Could you say a little more about how this causes pain? Thanks. Regards Steve -----Original Message----- From: Jim Dettman Sent: Wednesday, August 20, 2014 1:03 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Most common problems/situations Not sure what the goal is here, but I see these: 1. Inability to do a 3tier design. 2. VBA references/"runtime environment" as it's not a true .EXE. 3. Multiple versions of Office on the same PC. 4. Lack of 3rd party controls because Access does not fully implement the IDispatch interface. 5. Lack of control over the main Access window. as more of a pain because there's no real good solution for any of them expect #3 (sage) and still be an Access Developer. I suppose one thing beyond that which makes life really painful is the automatic save of a main record when you move into a sub form control. I'd have to say out of all the things taking Access "as is" and using it the way that it's was intended to be used, that one causes the most problems. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, August 19, 2014 12:08 PM To: Access Developers discussion and problem solving Subject: [AccessD] Most common problems/situations I'm trying to gather a list of the most common problems and situations faced by an Access developer (strictly referring to design/coding/form types/control types/classes, etc., and leaving aside problems such as time-and-billing, getting paid in a timely fashion, how to factor into your billing rate the depreciation on your hardware and software investments, etc.). The initial ones that come to mind are: - Input masks - Master/Detail forms (could be nested, as in Customers/Orders/OrderDetails) - Combo boxes (also involves Cascading Combos and NotInList behaviour) - List boxes (also involves NotInList behaviour) - Linked forms (a pair of forms; navigation on either causes navigation on the other) - Office Integration (links to Excel, Word, Outlook,etc.) - Custom Nav buttons (assuming you don't like those built-in) - On-the-fly creation of new forms/dialogs/reports - Search and Filter facilities - Reports scoped to either the current row, or criteria - API calls - Export current record/report to PDF and email same - (Advanced) Creation of custom classes, most commonly custom controls These are the common problems I have commonly faced and addressed. Do you have others to add to this list? Eagerly seeking addition to this list. -- Arthur -- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com