Savebutton Madness

[John S]

Hi all,

I am using a form for pet owner information, and a datasheet subform for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save button is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call a
recordset from the pet table based on the ownerID, and load the temporary
table. I get the pet table noting "deleted#" for each field initially, but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the data
appears fine, except (of course) the number of pets keep doubling. I have
tried deleting from the temporary table from the form calling the owner/pet
form/sub-form. Same problem. I have tried moving loading the temporary
table to other methods in both the form and subform. No Success. I am
weary about deleting on form onload (what happens to my temp table if there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some problem
with notation for a sub form.

Thoughts?

John S.
Aylmer, PQ Canada

 

[Dale Fye]

John,

Before you delete the data from the temp table, set the rowsource of
your subform to "". Then delete and append to your table, then reset
the rowsource of your subform to the temp table.

--
HTH

Dale Fye


Hi all,

I am using a form for pet owner information, and a datasheet subform
for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this
arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save
button is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call
a
recordset from the pet table based on the ownerID, and load the
temporary
table. I get the pet table noting "deleted#" for each field initially,
but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the
data
appears fine, except (of course) the number of pets keep doubling. I
have
tried deleting from the temporary table from the form calling the
owner/pet
form/sub-form. Same problem. I have tried moving loading the
temporary
table to other methods in both the form and subform. No Success. I
am
weary about deleting on form onload (what happens to my temp table if
there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some
problem
with notation for a sub form.

Thoughts?

John S.
Aylmer, PQ Canada

 

[Rick Brandt]

Hi all,

I am using a form for pet owner information, and a datasheet subform for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save button is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call a
recordset from the pet table based on the ownerID, and load the temporary
table. I get the pet table noting "deleted#" for each field initially, but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the data
appears fine, except (of course) the number of pets keep doubling. I have
tried deleting from the temporary table from the form calling the owner/pet
form/sub-form. Same problem. I have tried moving loading the temporary
table to other methods in both the form and subform. No Success. I am
weary about deleting on form onload (what happens to my temp table if there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some problem
with notation for a sub form.

Thoughts?

Yeah, that you're going to an awful lot of trouble and more importantly
time spent to implement a useless feature. Thin clients (like web pages
and terminals) have explicit Save buttons because of the nature of how they
work, not because it is inherently desirable.

Is there *really* a compelling design need for this or is it just what
you're used to? How often are people going to fill out an entire main and
sub records and then decide NOT to save it? If the answer is "never" then
you obviously don't need this feature. If the answer is "rarely", just
include a delete or VOID option. If the answer is "frequently" then I
would question why this is true. Are the people doing the data entry
completely incompetent?

A major consideration that I think most people who set up these explicit
save systems is this. If I concede the argument that deciding not to save
the record permanently is going to happen occasionally, at what point in
the process will this happen? My assertion would be that it could happen
at *any* time in the process. Since it could happen at any time it is just
as likely (or even more so) that the user will change his mind about the
record AFTER they have pressed the explicit save button as before they have
pressed it. In those situations you are right back to needing a delete or
VOID option anyway.

 

[Dale Fye]

Rick,

The reason I do these explicit save operations is that there is no way
to CANCEL a save operation if the form contains a subform, and you
have made changes to the subform. Sure, you can cancel (Undo) changes
to the main form, but your changes in to the subforms data are a done
deal.

Many of the applications I develop are used for what-if type
computations. Some of these require subforms for setting parameters.
If I change a parameter in a subform, then move the cursor back to a
control on the main form, the record in the dataset supporting the
subform gets saved, and I have no way of getting it back to it's
original value. If I use a temp table, then my user has the ability
to CANCEL or SAVE the entire operation.

--
HTH

Dale Fye

Hi all,

I am using a form for pet owner information, and a datasheet subform for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save button
is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call a
recordset from the pet table based on the ownerID, and load the temporary
table. I get the pet table noting "deleted#" for each field initially,
but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the data
appears fine, except (of course) the number of pets keep doubling. I have
tried deleting from the temporary table from the form calling the owner/pet
form/sub-form. Same problem. I have tried moving loading the temporary
table to other methods in both the form and subform. No Success. I am
weary about deleting on form onload (what happens to my temp table if
there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some problem
with notation for a sub form.

Thoughts?

Yeah, that you're going to an awful lot of trouble and more
importantly
time spent to implement a useless feature. Thin clients (like web
pages
and terminals) have explicit Save buttons because of the nature of how
they
work, not because it is inherently desirable.

Is there *really* a compelling design need for this or is it just what
you're used to? How often are people going to fill out an entire main
and
sub records and then decide NOT to save it? If the answer is "never"
then
you obviously don't need this feature. If the answer is "rarely",
just
include a delete or VOID option. If the answer is "frequently" then I
would question why this is true. Are the people doing the data entry
completely incompetent?

A major consideration that I think most people who set up these
explicit
save systems is this. If I concede the argument that deciding not to
save
the record permanently is going to happen occasionally, at what point
in
the process will this happen? My assertion would be that it could
happen
at *any* time in the process. Since it could happen at any time it is
just
as likely (or even more so) that the user will change his mind about
the
record AFTER they have pressed the explicit save button as before they
have
pressed it. In those situations you are right back to needing a
delete or
VOID option anyway.

 

[Albert D. Kallal]

There is a example of creating a un-do with a sub form in:

ACC2000: Microsoft Access 2000 Sample Forms Database Available in Download
Center
http://support.microsoft.com/?id=233324

ACC97: Microsoft Access 97 Sample Forms Available in Download Center
http://support.microsoft.com/?id=175066

 

[Adrian Jansen]

Maybe if a subform is just used for setting parameters, you dont want to
bind it to a table, just read in some data as the form opens, then allow
users to modify if necessary. That way no data gets saved back, and avoids
the issue.


--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

Rick,

The reason I do these explicit save operations is that there is no way
to CANCEL a save operation if the form contains a subform, and you
have made changes to the subform. Sure, you can cancel (Undo) changes
to the main form, but your changes in to the subforms data are a done
deal.

Many of the applications I develop are used for what-if type
computations. Some of these require subforms for setting parameters.
If I change a parameter in a subform, then move the cursor back to a
control on the main form, the record in the dataset supporting the
subform gets saved, and I have no way of getting it back to it's
original value. If I use a temp table, then my user has the ability
to CANCEL or SAVE the entire operation.

--
HTH

Dale Fye

Hi all,

I am using a form for pet owner information, and a datasheet subform for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save button
is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call a
recordset from the pet table based on the ownerID, and load the temporary
table. I get the pet table noting "deleted#" for each field initially,
but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the data
appears fine, except (of course) the number of pets keep doubling. I have
tried deleting from the temporary table from the form calling the owner/pet
form/sub-form. Same problem. I have tried moving loading the temporary
table to other methods in both the form and subform. No Success. I am
weary about deleting on form onload (what happens to my temp table if
there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some problem
with notation for a sub form.

Thoughts?

Yeah, that you're going to an awful lot of trouble and more
importantly
time spent to implement a useless feature. Thin clients (like web
pages
and terminals) have explicit Save buttons because of the nature of how
they
work, not because it is inherently desirable.

Is there *really* a compelling design need for this or is it just what
you're used to? How often are people going to fill out an entire main
and
sub records and then decide NOT to save it? If the answer is "never"
then
you obviously don't need this feature. If the answer is "rarely",
just
include a delete or VOID option. If the answer is "frequently" then I
would question why this is true. Are the people doing the data entry
completely incompetent?

A major consideration that I think most people who set up these
explicit
save systems is this. If I concede the argument that deciding not to
save
the record permanently is going to happen occasionally, at what point
in
the process will this happen? My assertion would be that it could
happen
at *any* time in the process. Since it could happen at any time it is
just
as likely (or even more so) that the user will change his mind about
the
record AFTER they have pressed the explicit save button as before they
have
pressed it. In those situations you are right back to needing a
delete or
VOID option anyway.

 

[TC]

(snip)

Many of the applications I develop are used for what-if type
computations. Some of these require subforms for setting parameters.
If I change a parameter in a subform, then move the cursor back to a
control on the main form, the record in the dataset supporting the
subform gets saved, and I have no way of getting it back to it's
original value. If I use a temp table, then my user has the ability
to CANCEL or SAVE the entire operation.

Sounds more like a spreadsheet application than a database one!

(Fiddle the spreadsheet paramaters; see if the result is good; then save or
do-not-save the changes.)

TC

 

[John S]

Can someone show me how to do validation on fields in a a subform datasheet
WITHOUT a save button? For example, what if we don't want to issue the same
licence number twice? How do I validate that in a subform datasheet entry? I
suspect that would take some tricky programming.

I'd like to thank Dale for the tip: I'll try it. Wish I understood more
about why this particular trick works.

John S.
Aylmer, Quebec Canada

Hi all,

I am using a form for pet owner information, and a datasheet subform for
information on each pet owned. Works fine in a bound form, subform
arrangement, but you can't use a true save button with this arrangement.
Want save button.

As one of the newsgroup experts said, the workaround for a save button is
to bind the datasheet to a temporary table. I tried to do this via the
on_load method of the main form. First, I delete whatever is in the
"temporary table" (i.e. a preestablished, but empty table), then call a
recordset from the pet table based on the ownerID, and load the temporary
table. I get the pet table noting "deleted#" for each field initially, but
if I go into and out of design more, the data is there.

The hang up seems to be with the initial delete. If I remove it, the data
appears fine, except (of course) the number of pets keep doubling. I have
tried deleting from the temporary table from the form calling the owner/pet
form/sub-form. Same problem. I have tried moving loading the temporary
table to other methods in both the form and subform. No Success. I am
weary about deleting on form onload (what happens to my temp table if there
is an abnormal exit?)[Doesn't appear to work anyway]
I have also been playing with requery, but perhaps am having some problem
with notation for a sub form.

Thoughts?

Yeah, that you're going to an awful lot of trouble and more importantly
time spent to implement a useless feature. Thin clients (like web pages
and terminals) have explicit Save buttons because of the nature of how they
work, not because it is inherently desirable.

Is there *really* a compelling design need for this or is it just what
you're used to? How often are people going to fill out an entire main and
sub records and then decide NOT to save it? If the answer is "never" then
you obviously don't need this feature. If the answer is "rarely", just
include a delete or VOID option. If the answer is "frequently" then I
would question why this is true. Are the people doing the data entry
completely incompetent?

A major consideration that I think most people who set up these explicit
save systems is this. If I concede the argument that deciding not to save
the record permanently is going to happen occasionally, at what point in
the process will this happen? My assertion would be that it could happen
at *any* time in the process. Since it could happen at any time it is just
as likely (or even more so) that the user will change his mind about the
record AFTER they have pressed the explicit save button as before they have
pressed it. In those situations you are right back to needing a delete or
VOID option anyway.

 

[John S]

Thanks for the reference: I'll check out how Microsoft does it. My concern
still remains validation of client input.

John S
Aylmer, PQ