That's why rookies (like me) grumble so much......but all this brings me
quickly to another question: have all yous "experts" ever developed with
other tools?
Yes. Just about every pc database product. FoxPro, Advanced Revelation, old
dbase products. Reflex, Knowledge man...and probably a few more I can't even
think of..
I also have some good experience in mini and mainframe database systems
also.
If your answer is NO, well I can understand why you get bothered if someone
whispers about your baby, but if it's a YES, worst then ever, I can't
understand how you have been developing for a long time without complains,
implementing "solutions".
It is not question of someone complaining (and, really..I did not really see
much of a complaint on you part anyway...and further..so what if you did
complain?...no big deal...we are all big boys!).
I not really worried about someone complaining about Access. I think we are
all too much big for that kind of ra ra stuff. (did we not leave that thing
behind in grade school..you know...c++ is better then Delphi, or VB kind of
things......lets leave that for the kids!....).
So, no, I really do welcome criticisms here. However, when those complaints
grow based on lack of knowledge..then I do start to have a problem.
And, I never have a problem with the above scernor anyway.
The design access in general makes sense to me. I also believe that things
work is the result of some real and I believe honest concepts on the part of
the developers. You, or I can disagree with how things work. (however, lets
make some honest efforts to "why" things work the way they work).
I mean, a person feels pain, and then asks the doctor for pain killers. It
is likely MUCH better for the doctor to find out why there is some pain
(like maybe the nail spike that has pierced the persons foot!). Everyone is
looking for the pain killer, but it takes real effort to find the source of
the pain. Everyone wants the quick and easy solution to life..and it don't
exist!
You're simply speaking like other ACC. developers that were trying to
convince me that it is a smart product and that I was too rookie to
appreciate it's powerful features; the same reason whay someone else had to
write hundres (or thousands ?) lines of code to get a record highlight.
Gee, Atlas, if I came accross that way..then I do apolbige. That is not my
intesions at all. I am realy *very* sorry if that is the kind attitute i
dispalyed. And, yes..I most certanly DID pull some sarchasim in my
response..but so did both of the orignal posters here. Sure, one can make a
bit of fun about ms-access...and even take a few pot shots....(but then
don't be surposed if a few take some shots back!).
I actually do think access is a smart product, IMHO. And, we do have
conditional formatting in ms-access now to highlight fields/records.
Conditional formatting solves a LARGE number of highlight type problems.
This feature was added based on requests from users like you and me! And,
there is many high quality add-in that one can purchase if need be.
On the other hand, you do seem to be pointing out what you think is a
ms-access shortcomming. You seem to be stating that the product does not
have a reasonable soltion to what you want to do? Up to this point..no
problem..but you now are saying the desing is wrong! When did you become the
all seeing, all knowing lord of the universe database design guru?
I just want to be clear here, and I have no beef at all with you. I hope I ,
and others here can help you come up with a clean, and easey, and workable
soltion to your needs/problems. That is really all I want here!
The fact is, that software development takes time and skill, and there is no
substitute. There is no shortcut to becoming a doctor either...but some
would love to find that shortcut, and the instant pain killer. Life,
medicine, and yes even software development don't work this way!
And, I do think ther is a very easy soltion to your problem...
Why should I parse something that hasn't changed??
Actually, there is lots of reasons for the above:
One reason might be that you don't want some fields to be blank, but NOT
blank ONLY if some other fields have particular values in them. I can't give
a error message when editing those other fields as the user may not yet have
gotten to entering those empty, but required fields? Those empty fields have
not yet changed..but they are now required. And, if the user does NOT enter
values, then I most certainly do have to parse the results..don't I?.
The above info was not a criticism, but I was just pointing out that often
code in JUST the before update event of a control is NOT enough to solve
problem at hand: I quote:
So, are you suggesting that one can't come up with a lot of scenarios where
the ONLY the before update event of control on the form is enough? I can
think of a zillion examples.
Heck, if a user checks a box, or sets a field for martial status = divorced,
then I might have a general comments, or text box that the user MUST fill
out to explain the reasons for the divorce. And, of course those general
divorce comments are now required. If the user don't edit the divorce
comments field....what to do? So, yes...often we do need to parse, and give
error messages for controls that the user does not edit. This is in fact
standard fair in a lot of applications. (and, now..how compliex will your
bail out code become?..hum?).
Again, I don't know if the above is YOUR case. I think it is important to
point out that you might have *often* check in two places. So, I can
certainly come up with a ton of examples where the controls before update
event will NOT cut it. That is my point here! So:
Why should I parse something that hasn't changed??
Fine..in YOUR case..the above is fine..but what about the rest of world?
Must we always conform to your world?
What was/is your point on this issue? Hum? If YOUR point was that you don't
have other dependencies in YOUR case..then fine! However, don't tell the
universe that people don't need to check or parse fields values when they
have not changed! This kind of thing would thus only reflect YOUR view of
the universe. At least in my case I am acknowledging both scenarios.
No I don't; In a well designed product, users would get stuck in that field
until cancel or correct.
That is according to your view! How are you going to stop the person from
hitting the reset button on the computer? Why such a all or nothing point of
view here? I really don't think it is a good idea to trap the user in the
record..fustrated users will just hit ctrl-alt-del..or do other nasty
things! (I seen this time and time again).
I mean, really, why must the above be so? Why now have you become the judge
and jury on how a database system should work?
What happens if the user just realized they are working on the wrong
name/record? So, they whack the x to close, and they get a message about not
being able to save the current record..and do you really want to exit? This
seems like a perfectly reasonable scenario in many cases. Why not let the
user exit..and not save their changes? If they been working on the wrong
record..I would think that is quite reasonable solution?
So..this is how ms-access works. I think this is reasonable solution (and,
obviously..you don't). Ok, so, we see things differently here. However, I
don't think you should get a user stuck in a record. You now going to have
users start calling the support help desk because they accidentally edited
the wrong record?
And, at the end of the day..if YOU do NOT want to give users the choice to
bail out..then you CAN write some code. And, the amount of code I
showed...is what less then 10 lines of code? I could again be really mean
here ask how come one is too lazy, and how little lack of effort do you want
to make here? I will not do that..but golly..do you really think this is so
bad?
The standard ms-access functions give the user a chance to bail out..and NOT
save the record?
So, your way with no choice...or give the user some choice? Be honest
now..which is a better design? At least I am open minded enough to figure
out that some people might want exit and not save the record. Lets not view
the world through a straw here, and always think thinks MUST work one
way..and that is YOUR way???.
"migth" sounds good here, but what if we don't?
Gee, and what ..less then 10 lines of code?
Again, I really don't want to press on this issue much..as there are simple
solutions...
The whole problem here is that you got some advice that it is not possible
to come up with a clean and workable solution. However, the reasons for you
getting this advise was the lack of knowledge on the other posts part. So,
now you got two people setting here. One says yea.....there is no good
solution..and the rest of the crowd follows along..and also goes
yea....there is no good solution. How big do we want this crowd? Should I
just stand by and let another 200 people jump in and start shouting also?
This just starts to sound like a bunch of people at a political rally
chanting down with <insert whatever you don't like here> rally.
You don't think it is a disservices to other readers to be told that a no
solution exists here? Gosh, I thought we got out of the dark ages a long
time ago when a bunch of people tell other people things to hide solutions!
Why now cheer and tell people there is no solution? Why be so mean to so
many people, and hide solutions?
So, I have zero problems with some criticizes. In fact, I welcome new ideas!
I am least looking for good arguments and I want everyone to make their
case, and make their point. I make no claims that things MUST work my
way...but I will certainly give my arguments as to why I think so. I think
allowing users to bail out of a screen without a save is a good
solution..since it means users can then get out of the application (nothing
is more frustrating to getting stuck in some piece of software to a user).
The only real fear I have is when people criticize things..and don't make a
effort to figure out the how's and whys'. When we let crowds of people grow
and criticize things based on lack of information, then you can convince
these people that just about anything is wrong. After that...you can darn
near get these people to do nearly anything for you!
So, really, I just don't want a crowd of people to start growing in this
post agreeing that there is no reaonsoable solution when in fact there is.
It just seems un-fair to hide solutions, and to tell these people that no
good solution exists. In fact, it reaches point of being dishonest.
Make your case....as I really do welcome it.
If you think that using about 5 lines of code to solve this problem is too
much for a solution..then there is nothing I can do.
However, I am here standing and waiting to answer you questions..and I
gladly will do so!
