jack drawbridge
jackandpat.d at gmail.com
Thu Aug 21 07:29:52 CDT 2014
Arthur, Thought I'd pass this on since it came by today and seems to fit your request. " In the user interface - forms, query criteria, - where users enter dates, MS assumes the format is the system setting, even if the date is enclosed in # tags, as it might be in query criteria. I have always been led to believe that any date between # marks had to be MDY (regardless of system setting), but no. Only sometimes. You'd think MS could enable users to set the date format that Access uses everywhere, including SQL and VBA, regardless of the system date format setting. I wonder how many non-USA users have been caught by this, without realizing it? " On Wed, Aug 20, 2014 at 1:34 PM, Jim Dettman <jimdettman at verizon.net> wrote: > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >