Re: Access 2007 Technical Questions

Let me clearify up one thing as you seem to have misunderstood me when I
mentioned validation rules. Yes, I fully understand the order of the
sequence of the events, and secondly, I have done a lot of things with
various programs.

I get the sense you think I'm refering to the Validation rules that one sets
up in the controls or on the fields within the tables in the BE DB. Forget
about those fields (Validation Rule and Validation Text on both Controls and
Fields within Tables). I instead would use any of the events that I can
properly use. The events that I have used are, Enter, GotFocus, KeyDown,
BeforeUpdate, AfterUpdate, Exit, LostFocus, and in few instances, MouseDown
or MouseMove. I use KeyDown instead of KeyPress cause as a developer, I
have more control via the KeyDown Event than I do with the KeyPress Event,
as the KeyDown picks up on things that the KeyPress doesn't, and the things
that the KeyPress does pick up, I can get just as easily with the KeyDown
Event.

Also, before you start accusing people that they don't know how a program
works, try to think it through to see what they are getting at. I think the
reason why you said that I have my own perception is cause of the fact that
I am a stickler on data validation, but at the same time, I'm also a
stickler on user friendliness, which I can't get both with BOUND
FORMS/CONTROLS. I have gone over this several times in the past about this
very issue on the newsgroups, and others finally realized what I was getting
at and agreed with me, it's not possible to do within Access for bound
forms/controls of what I'm after. Cause of the lack of having the
CausesValidation Property and Validation Event, I have had to create my own
custom centralized error checking code, which only works for unbound
forms/controls. Well it could be done for bound forms/controls, but still
run into the user friendliness issue that the centralize code address, thus
why I say it only works for unbound forms/controls.

Here's a link to an example that I'm talking about:
http://www.thescarms.com/vbasic/VB6Features.asp

Within this example, you see a dialog box with 5 different command buttons.
All 5 of the command buttons has the property, "CausesValidation". All of
them except for the one that shows as "Quit" has this property set to "True"
while the one for "Quit" is set to "False". The textbox itself has the
"Validation" event.

If you click on any command button other than for "Quit", the Validation
event on the textbox is triggered without the textbox losing control, which
is more or less the same how Access works.

Now, if you click on the "Quit" command button, this is where VB6 differs
from Access. Access would still go through the validation process via the
set of events that's on the textbox control, but in VB6, cause the
"CausesValidation" property on the "Quit" command button is set to "False",
there is no validation ran against the contents in the textbox, thus if
there's no string in it, VB6 will close out the program, but if that was
done in Access, the command button would never get the focus cause it would
have errored out and the focus would still be stuck on the textbox.

You right in the sense that the other issues that I'm having is as a result
of this issue that I just went through the illustration. With me having to
unbind all forms/controls in order to attempt to restore the user
friendliness of the forms while still keeping the stringent data validation
and to be ran only at the times when it's proper to be ran, these other
issues has surfaced. However, that doesn't mean that these issues doesn't
exist in Access itself.

If MS fixes these issues among others, then I may lay claim about MS Access
being multi-user worthy, but until such thing takes place, I will not lay
that claim.

Another big thing that I don't like about MS Access is the size limitation
of DB files, thus I had to setup multiple BE DBs (about 8 of them) to get
around this issue.

--
Ronald R. Dodge, Jr.
Production Statistician/Programmer
Master MOUS 2000

"Klatuu" <Klatuu@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BCB0BD34-F7EF-418E-BDD5-42AD35759A80@xxxxxxxxxxxxxxxx
Neither Access nor any other database application is perfect; however,
reading your post I get the sense that rather than learning how to use
Access
correctly, you have your own preconceived notions about how it should be
and
are trying to force fit it to your way of thinking. Some notes on you
issuses follow:

"Ronald Dodge" wrote:

I have exerted a lot of energy in the past testing things out in Access
2000/2002/2003, and here's the issues that I have faced.


Issue 1: Error checking isn't user friendly (Very Critical)

The biggest issue that is the very reason why I have had so many other
issues in Access is the fact that Access is not very user friendly when
it
comes to error checking, especially for mouse users. Most times, you
want
the validation rules to run, but there are a minor few possible reasons
why
you may want to bypass the validation rules such as user clicking on the
"Help" command button (if there is one on the form), resetting the form,
or
even backing out of the form as 3 possible reasons why to bypass the
validation rules. However, when the user goes to click on a command
button
on the form, all validation rules on the active control are processed,
and
if any of those validation rules causes the control to be in error, the
Enter Event doesn't even take place on the command button cause the
focus is
forced to stay on the active control rather than to transfer to the
command
button.

Access, being part of Office, caters to the casual user. Validation Rules
are there so that a non developer can apply a rudimentary level of error
checking. Most professional developers do not use Validation rules. They
code their own to make the user friendly.


To get around this issue, I had to mimic the CausesValidation Property
and
Validation Event as has been setup in VB6, which meant in order to get
around this issue, I had to UNBIND every single form and control else
this
wasn't going to work. It took me a total of 3 full months to do the R&D
to
get around this issue. Therefore, I ask, "Does Access 2007 have the
CausesValidation Property and Validation Event, that is comparable to
VB6's
property and event?"

Using unbound forms is a typical mistake made when a user doesn't fully
understand how to use them. If you understand the event sequence, the
behaviours of the events, and how to properly address the issues.



Issue 2: EditMode within DAO programming loses it's value for no
apparent
reason (Critical)

Initially, I was using DAO to get around the issue above as in order to
get
data to the any of the BE databases with all forms and controls unbound,
can
only use ADO or DAO programming language to manipulate the data.
However,
there were instances that I found, when the code initially put the
recordset
into Edit Mode, even with the variable set at the module level of the
form,
before it even reaches the Update Method, the EditMode property no
longer
has it's enum value that it suppose to have. This more or less has
rendered
DAO programming useless.

I have not encountered this issue with the edit mode, perhaps because I
don't have to do as much coding to manipulate the data. This problem
sound
like a byproduct of using unbound forms.


Issue 3: ADO programming doesn't allow for DynamicCursor Keyset against
a
Jet Engine (Critical)

This one is actually documented, so I ask the question, how is one
suppose
to setup a recordset using a Jet Engine to be able to see changes within
it
when changes do take place? Without this capacity, it has rendered ADO
programming useless. Does Access 2007 address this issue?

Here, I agree with you. I don't much care for ADO and I only deal with it
if I have to work on someone else's application.

There is a 4th issue as well, but it's the above 3 issues that has more
or
less turned me against from using Access as with those issues above,
Access
is not a worthy DB program for a multiple user environment. I was going
to
have my own financial stuff stored within Access, and then allow my wife
some capacity to record some things, but with the issues above, it's not
stable enough to have something like that setup. Instead, I am still
using
Excel for all of my financial planning and tracking stuff, which that
has
gotten to be so large, I have already broken that 1 file down into 4
files
and it's about to get split out to a 5th file with the data grouped in
the
following categories:

Access is a worthy multi user environment when properly implemented by a
professional.


Economy (This contains information about the economy including economic
historic data, which impacts inflation, thus also impacts the spending
side
of the equation)

Debt

History (Our own financial history)

Investments (This isn't actually broken out yet, but it soon will be)

Planning and Summary (This file pretty much contains everything else
that
doesn't fit into any of the above categories and currently also contains
the
investments)


Issue 4: Listbox properties doesn't update until it has lost focus when
it's allowed to have multiple selections (Moderate)

This issue caused a lot of problems for me as well. Without addressing
this
issue, records wouldn't be updated properly. To get around this issue,
I
had to create a class module and put in a set of codes to more or less
be
able to record all of the various behaviors, just so as I can get an
accurate picture of what's taking place with the listbox. All of the
things
done to the listbox is retained, but it's properties are either not
updated
or if they are, the properties are only returning their old values,
similar
to what happens when a DB transaction is taken place by recording, but
prior
to those transactions to being committed, they are only in a temporary
storage, but once committed, the tables are updated with the recorded
data
from the transaction.

Of course, this meant that I had to learn every single behavior of the
listbox from using both methods, mouse and keyboard. Not only that, but
I
found in few circumstances with the right combination of the keyboard
and/or
mouse actions on the listbox, the listbox itself freezes up and does
nothing
else, which the only way to get away from that issue has been to back
out of
the form, and then go back into the form.

Sincerely,

--
Ronald R. Dodge, Jr.
Production Statistician/Programmer
Master MOUS 2000





.

Loading