Need help with Access decision

  • Thread starter Thread starter aualias
  • Start date Start date
Albert,

From the documentation, it seems that the Unload event is the place to send
an e-mail. Since you can cancel the form's closing in that event, all the
data should still be there and the user cannot enter more.

To be honest, this form does work now (with my terrible kludge - global
variables for the e-mail). To fix the many problems correctly, my client
will just have to spring for some redesign. When they click the button to
enter a new job, it should certainly not be in the same window as the job
that they are on. That way, if they click on the new job button again it
will just pop up another new job window. Also, I like David's idea of local
tables for entering/updating data. That way they can accept or cancel all
input as a transaction.

You all have convinced me that they should not move away from Access unless
their needs change dramatically. I shall let them know. You have also
convinced me that being able to write COM code in C++ does not exempt me
from biting the bullet and learning the tools when working with Access. At
a bare minimum I have to know the event model and write some test apps to
see exactly how things work.

My client, as do many, does not want to spend too much money on this
application on which their livelihood is based. I am working for a friend
who is trying to keep the price down so he can keep the client. It has not
inspired me to spend much time in getting up to speed. Now I have to lay
down some conditions that I can work under. They do not have to pay for my
learning curve, but they do have to give the ok to enough hours to
restructure the application and to make the job worth doing.

Thanks to all of you. It's been a great help.

Alfredo
 
aualias said:
When they click the button to
enter a new job, it should certainly not be in the same window as the job
that they are on. That way, if they click on the new job button again it
will just pop up another new job window.
Click to expand...

Why have two forms, one for new jobs, one for existing jobs? I will
frequently put a New button on a form which does nothing more than
Docmd.GotoRecord acNew. Warning, air code. Or am in misunderstanding
something?

Or on a search form I will add a button to open the data entry/view
form but in Add mode.
Also, I like David's idea of local
tables for entering/updating data. That way they can accept or cancel all
input as a transaction.
Click to expand...

Again why? I've never seen the use for this unless you're dealing in
an environment where the user, such as a person in a call centre, is
dealing with someone who changes their mind a lot? Surely there is a
reason to enter the data in the first place.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
david epsom dot com dot au said:
4) Our large application has now well over 1000 forms, and
is commercially deployed: we are not experiencing any
stability problems.
Click to expand...

You haven't come across the following problem then?

Note that there is an unusual problem when creating MDEs.

ACC97: "Microsoft Access Was Unable to Create an MDE Database" Error
Message 177620
ACC2000: "Microsoft Access Was Unable to Create an MDE Database" Error
Message 202304

A97 allows a total of 1024 open TableIDs at a time, A2000 2048. Thus
if you have somewhere close, no definition of close, to 1024 objects
in A97 with code then you could run into troubles.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
tables for entering/updating data. That way they can accept
In our case, the data goes to an action table, a movement table,
an audit table, and a history table. Data comes from user entry,
the history table, or an action table. The data source tables have
slightly different formats from each other, and sometimes it is
necessary to bring back data from the movement table as well.
It is possible to reduce the number of forms, and easier to optimise
the data load process, when using unbound data, and it simplifies
the transaction process when saving data. We could just use an
unbound form, but bound forms and table data offer a number of
advantages in Access, so we bind to a local table.

We think that people doing New Records don't need undo very much,
but that people doing Modifications should be able to undo.
Unfortunately, Access sometimes wants us to commit, before doing
some lookup and calculation queries that need the data, or changing
focus to another form. For us, the easy way to commit temporary
(uncommitted) data, is to commit it to a local table. There are
other ways, but this works for us, and it matches our needs as
outlined above.

It is not something we do on all, or even most of our forms. We have
20-25 of these forms out of the hundreds in our primary application.
Most of our forms are bound to only one table, and the data is
automatically committed if the user closes the form or changes records.

Historically, most of the system (all those simple forms) used
separate data entry and data modification forms. We have moved
away from that for aesthetic reasons, but it still seems to me that
it is tricky to get good control of commit/undo on a bound form
where the data may be either 'new' or 'dirty'

(david)
 
4) Our large application has now well over 1000 forms,

Yes, I wondered if I should explain that.

We use code libraries. We got the system to work as
one mde in A2K2 when that came out, but it can't be
compiled as one mde in A97 or A2K. It has grown more
since then, and we have not retested. There are 10
large MDE's of 50-200 forms, 6 other small mde's, 4
dll's, and one executable.

I decided than the main question was if Access worked
with large applications, not the mechanics of how it
is done.

Sorry.

(david)
 
david epsom dot com dot au said:
Yes, I wondered if I should explain that.

We use code libraries. We got the system to work as
one mde in A2K2 when that came out, but it can't be
compiled as one mde in A97 or A2K. It has grown more
since then, and we have not retested. There are 10
large MDE's of 50-200 forms, 6 other small mde's, 4
dll's, and one executable.

I decided than the main question was if Access worked
with large applications, not the mechanics of how it
is done.

Sorry.
Click to expand...

No problem. I was just quite curious. I know that sooner or later I'm
going to hit the same problem and have to split up that honking big
MDB. Nice to hear that all this works so well.

Fortunately there is one particular group of forms, reports and code
that can be moved into it's own MDB with very few problems.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Back
Top