On Mon, 4 Jun 2007 07:38:55 +0100, "Baz"
wrote:


Ohhhhh I begin to see where you are coming from. You're talking about
entering records in both a main form and a subform as a single logical
transaction. Not a requirement I have often encountered, although I have

I'm not sure how you could avoid it other than (off the top of my
head) putting the main form data onto a subform also. Anyway, in my
situation users enter main form data and then go on to enter subform
data. That is in a perfect world. They may try to enter the subform
data first which sets off an unhappy chain of events in bound forms.

Yes these (sub)forms are bound also, but not to the 'permanent' tables
so nothing is entered into the db until the operator (and my
validation code) has clearly indicated that the data is cleared to be
processed. BTW, deletes are often not treated casually and may only
allowed by certain operators and even then tracked so the
unintentional saving of a record is not a trivial event.

I may also deal with this in a variety of other ways, including hiding
subforms until essential data is entered. Sometimes that works well -
sometimes not. These strategies can't be divorced from the real world
situation. I mean you have to put yourself in the data entry person's
shoes and tailor the form to their skills, needs and working patterns
and also anticipate the kind of mistakes they will probably make and
figure out the best way to recover from them.

needed to do it once or twice. Would be interesting to hear more about your
circumstances.

Maybe it is just a difference in style. I did not look for ways to
avoid this. It (unbound forms) seemed the best way of the various
alternatives to make the users the most productive and avoid data
entry errors and frustrations, particularly as my users are mostly
not native English speakers nor particularly computer savvy
-suggesting using the ESC key to reverse a data entry would just be a
waste of time as would be suggesting using the built in Access menus,
which I do not expose to them. I don't regret it - the system works
well, is easy for them, and in fact data entry errors and service
calls were few (I am thinking of the app with the heaviest use of
unbound forms).

Presumably when you use local tables in an mdb, temporary tables in SQL
Server or whatever, you are binding forms to them? Otherwise why use tables
at all as your "temporary" repository?

Yes, the subforms are always bound to temporary tables - either Access
or MS SQL temp tables or tables used to store the data temporarily
until it is written to the main tables. The main form may or may not
be. I've also tried binding to recordsets with mixed results. For me,
an added advantage of using tables over code is it is easier that way
for me to go back a year or two or three later and quickly refresh
myself as to what the logic in that part of the application is.

I find all the comments about my approach being the worst of two
worlds interesting. To me that implies I not only wasted a lot of time
but also produced an inferior product. Yet I've taken on jobs that
others have tried and failed to complete and produced a result that
has satisfied the requirements of the clients which is demonstrated
not only in their initial remarks and experiences, but by the fact
they by and large have continued to use and rely on the apps for years
and years.

In fact, other than perhaps a slicker look using VB, I can't see how
the apps could be better! And with the last and most complex one I had
a lot of time to mull over that, as I worked as I.T. Admin for that
client for 5 years after creating the app, did some tweaking on it in
that time, but never had cause to question the underlying
construction, including form strategies.

It might be the worst of one or even two worlds for a completely
different applcation though - which could be said of almost any
approach. ;-)

Peter