Access crappy event model.......

  • Thread starter Thread starter Atlas
  • Start date Start date
A

Atlas

It's a while I've been tryng to work with Access 2003 and after all I can
easily state that it's CRAPPY and absurd.
Ten years ago I've designed a small app with Borland Paradox for Windows 7
and the event model was far better than what is Access today.
If you have to design a simple form it's ok (but slow), but when you must go
a little bit more complex, troubles arise.

A few examples?
- It doesn't manage record events (continuos form and datasheet view)
- some functions are unreliable, like sum; when managing data on a form
referring to the control holding a sum, in certain conditions the sum
doesn't reflect the updated value (if you move the focus from the updated
field to another field in the same record)
- if you want to update a field in a continuos form from vba, all fields of
the same column change value)

......................crazy....
 
You really don't ask any questions here, you just complain.

Most of us are able to design complex applications that work very well. I
do not have any of the propblems you mention below.

Since Access is so crappy and absurd, I suggest you go back to using
Paradox. You can probably find a copy a t a flea market real cheap.



It's a while I've been tryng to work with Access 2003 and after all I can
easily state that it's CRAPPY and absurd.
Ten years ago I've designed a small app with Borland Paradox for Windows 7
and the event model was far better than what is Access today.
If you have to design a simple form it's ok (but slow), but when you must go
a little bit more complex, troubles arise.

A few examples?
- It doesn't manage record events (continuos form and datasheet view)
- some functions are unreliable, like sum; when managing data on a form
referring to the control holding a sum, in certain conditions the sum
doesn't reflect the updated value (if you move the focus from the updated
field to another field in the same record)
- if you want to update a field in a continuos form from vba, all fields of
the same column change value)

......................crazy....
 
It's always the machine ... never the operator!
You're just new to a complex Form event model which is far superior to
any other DB development platform.

Responses inline.
--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Atlas said:
It's a while I've been tryng to work with Access 2003 and after all I can
easily state that it's CRAPPY and absurd.
Click to expand...
How can you expect to master a new, complex development platform in a
short period of time. There's a reason that Access is the world's
leading front end development tool for databases.
Ten years ago I've designed a small app with Borland Paradox for Windows 7
and the event model was far better than what is Access today.
If you have to design a simple form it's ok (but slow), but when you must go
a little bit more complex, troubles arise.

A few examples?
- It doesn't manage record events (continuos form and datasheet view)
Click to expand...
Be specific. There are form events and individual control events for
every object on the form whether the form is in Single, Continuous or
Datasheet view.
- some functions are unreliable, like sum; when managing data on a form
referring to the control holding a sum, in certain conditions the sum
doesn't reflect the updated value (if you move the focus from the updated
field to another field in the same record)
Click to expand...
Just use the Requery method of the calculated control you want updated
when you either leave the control that effects the calculated control or
upon entering the calculated control. Access offers very fine control
over its controls.

- if you want to update a field in a continuos form from vba, all fields
of
the same column change value)
Click to expand...
For Unbound Controls that statement is partially true. In either case,
A2K or higher offers Conditional Formatting which will resolve your base
issue here.
 
It's always the machine ... never the operator!
You're just new to a complex Form event model which is far superior to
any other DB development platform.
Click to expand...

LOL!

I may be a rookie, and certainly I am. But the same "operator" never had to
manage so many workarounds to make it work. Force .requeries, .recalcs so
many times, partially hiding combo boxes behind a text box to prevent
unwanted results on continuos forms it may lead into a not-so-well-designed
product.

It's easy to say "go back to your Paradox" (unsupported); I was just stating
that the having a giant as MS behind maybe they should have pull out a
better design from it, and that's probably why the majority of the coders
out there prefer to use Delphi rather then MS products.
 
I may be a rookie, and certainly I am. But
the same "operator" never had to manage so
many workarounds to make it work.
Click to expand...

I observe that it is worth investing some time and energy into learning how
_any_ product works so I can work _with_ it, instead of _against_ it. I can
assure you that time and energy invested in learning how Access works will
pay you enormous dividends. I really think, in the long run, it is more fun
that working against your tool and complaining about it in newsgroups.

Delphi is not something that you can compare against "MS products" and,
although it does have its adherents, I would seriously doubt that the
majority of _developers_ prefer it to all MS products. I note that you say
_coders_, though -- not sure what the point is. I personally never cared for
Delphi, nor for OPAL in Windows Paradox, because I personally never cared
much for Pascal (from which they are directly descended).

Larry Linson
Microsoft Access MVP
 
Larry Linson said:
I observe that it is worth investing some time and energy into learning how
_any_ product works so I can work _with_ it, instead of _against_ it. I can
assure you that time and energy invested in learning how Access works will
pay you enormous dividends. I really think, in the long run, it is more fun
that working against your tool and complaining about it in newsgroups.

Delphi is not something that you can compare against "MS products" and,
although it does have its adherents, I would seriously doubt that the
majority of _developers_ prefer it to all MS products. I note that you say
_coders_, though -- not sure what the point is. I personally never cared for
Delphi, nor for OPAL in Windows Paradox, because I personally never cared
much for Pascal (from which they are directly descended).
Click to expand...

Ditto ;

Wirth developed Pascal to teach structured programming in the days when
getting computer time was difficult to literally impossible. It was never
meant to be compiled.
Wirth himself said that it should not be used and Modula-2 was his answer.
 
I observe that it is worth investing some time and energy into learning
how
_any_ product works so I can work _with_ it, instead of _against_ it. I can
assure you that time and energy invested in learning how Access works will
pay you enormous dividends. I really think, in the long run, it is more fun
that working against your tool and complaining about it in newsgroups.
Click to expand...
(CUT)

Larry I partially agree with you; I'm definitively not wishing to fight
against my development tools even if it looks like. All I wanted to know was
if any other mate here around had/has the same troubles I'm having, just to
understand if my approach is wrong or wright.

And BTW, to my eyes, it looked like that obvious and common tasks (like
enabling,disabling single records on a CF or DS, or updating a combo box in
a CF/DS) can bring you quickly to complex management.

I'm having fun with Access, but you must admit that important aspects (like
record events management) were left out from Access designers and IMHO it's
a big lack.
 
You're just new to a complex Form event model which is far superior to
any other DB development platform.
Click to expand...

LOL!!!!

You make me laugh!!! :)))

Look at the amount of code you had to write down just to make a record
higlight!

The community probably thanks you (and I will soon), but don't tell me that
this is smart!

Bye Steve
 
Atlas said:
And BTW, to my eyes, it looked like that obvious and common tasks (like
enabling,disabling single records on a CF or DS, or updating a combo box in
a CF/DS) can bring you quickly to complex management.
Click to expand...
I'm not sure what DS or CS is in Access but updating a combo box or
enabling/disabling one or more records is hardly complex.
WRT the combo it does take a few lines of code to do it right but it is
extremely rare for me to have the need to update a combo when more
information is not required.

Pseudo code
IF Notinlist then
VByesno = "Do you want to add this?" etc, etc
IF VByesno then
open the form and fill the value
requery the form
end if
end if
 
Back
Top