Opening Form without data retrieved

[Ronald Dodge]

When a bound form is openned, it automatically loads the first record of the
bound recordset. How do I prevent this from happening?

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[ruralguy via AccessMonster.com]

Leave the RecordSource blank until you want records, then set the
RecordSource.

 

[fredg]

When a bound form is openned, it automatically loads the first record of the
bound recordset. How do I prevent this from happening?

What do you wish to happen when the bound form opens?

 

[Ronald Dodge]

Would like to be opened as a blank form, which I seemed to have resolved via
the DataEntry property on the form. My computer intuition was telling me
not to unbind it as there's probably a whole host of things to take into
account when that happens, which I already been down the route of unbound
forms and didn't care for certain things not working properly such as the
EditMode property not working properly on DAO recordsets, and ADO not
allowing for a dynamic cursor keyset against a JetEngine.

In the past, I didn't care for the bound forms cause of the way the events
works for going from control to control as far as control level error
checking is concerned as opposed to form level error checking. However, I
have created a work around for that issue.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[ruralguy via AccessMonster.com]

Setting the DataEntry property TRUE puts you on a new record if that is what
you want. I was not suggesting unbinding the form but simply leaving the
RecordSource blank until you want records. It is also a way to get forms to
load faster.

 

[Bob Quintal]

But isn't the RecordSource property on forms what's used to
bind forms, thus when you take it to a value of "", you have
essentially unbound the form?

Well, yeah, but!

The idea is to programatically set the RecordSource once the user
has set a filter to return the records wanted, or indicated that he
wants to enter a new record.

 

[Ronald Dodge]

But isn't the RecordSource property on forms what's used to bind forms, thus
when you take it to a value of "", you have essentially unbound the form?

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[ruralguy via AccessMonster.com]

As Bob said, yeah, but...

You design the form while it is bound and get it to work as you desire bound
to your query. The you set the RecordSource to "" and don't set it bact to
the query untile something the user does needs records. Simple, right?

But isn't the RecordSource property on forms what's used to bind forms, thus
when you take it to a value of "", you have essentially unbound the form?

Setting the DataEntry property TRUE puts you on a new record if that is
what

[quoted text clipped - 23 lines]

 

[Guest]

Hi Ron

I would tackle this scenario by going straight to a new record, because
using the DataEntry method would not allow changes and going back to the
records... of course this is all up to you and how you want your users to
interact with the form.

Hope this helps.

--

---
The glass is neither half empty nor half full. It is simply twice the size
it needs to be.

Would like to be opened as a blank form, which I seemed to have resolved via
the DataEntry property on the form. My computer intuition was telling me
not to unbind it as there's probably a whole host of things to take into
account when that happens, which I already been down the route of unbound
forms and didn't care for certain things not working properly such as the
EditMode property not working properly on DAO recordsets, and ADO not
allowing for a dynamic cursor keyset against a JetEngine.

In the past, I didn't care for the bound forms cause of the way the events
works for going from control to control as far as control level error
checking is concerned as opposed to form level error checking. However, I
have created a work around for that issue.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Ronald Dodge]

The way I'm invisioning the form is to have 4 command buttons, one to
inquire, one to add, one to update, and one to delete. Each have varying
rules. More or less, I'm using the JDE GUI interface as a model so as to
keep similar things alike for the users, but yet, making up for the short
fall of what data is stored in JDE (or should I say the lack of data stored
in JDE due to how certain things are setup in JDE). Therefore, the entry
mode would be determined by which command button (or hot key) is used to
determine how the data is interacted with the BE database.

When it comes to binding and unbinding forms, I want to make sure I'm
covering myself as from a programming stand point of view. I have to be
able to catch things from pretty much every stand point of view reasonably
speaking. What sort of things takes place? What issues may I face? What
do I need to take into account? These are just some of the types of
questions that I have to ask myself as a programmer/developer

Sorry if I seem to be too nick picky, but it's me paying attention to
details and covering myself from the various angles that has saved my butt.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Bob Quintal]

The way I'm invisioning the form is to have 4 command buttons,
one to inquire, one to add, one to update, and one to delete.
Each have varying rules. More or less, I'm using the JDE GUI
interface as a model so as to keep similar things alike for
the users, but yet, making up for the short fall of what data
is stored in JDE (or should I say the lack of data stored in
JDE due to how certain things are setup in JDE). Therefore,
the entry mode would be determined by which command button (or
hot key) is used to determine how the data is interacted with
the BE database.

I usually use a menu form to hold buttons that give those
options, which opens the form in whichever mode I need, becaue
it's much simpler to code as a separate form. However your
approach is just as valid.

When it comes to binding and unbinding forms, I want to make
sure I'm covering myself as from a programming stand point of
view. I have to be able to catch things from pretty much
every stand point of view reasonably speaking. What sort of
things takes place? What issues may I face? What do I need
to take into account? These are just some of the types of
questions that I have to ask myself as a programmer/developer

Personally, I think I would keep the recordsource bound, but
change the recordsource to suit the mode.. You could create a
query that will return no records and bind to that.then when you
click on a button to search or update, you switch to a
recordsource that does return records.

Sorry if I seem to be too nick picky, but it's me paying
attention to details and covering myself from the various
angles that has saved my butt.

 

[Bob Quintal]

By the way this is looking like, it's looking like I will need
1 VBA variables per field on the form for what the user types
in. I will then need to use a separate recordset to pull and
maintain which record was inquired on, if any. I already
created a separate recordset for synchronization purposes.
This same recordset will be used for that inquired record
purpose as well. Looks as though I will loose the Pessimistic
locking method option due to the bound form issue as this will
be unbound most of the time, and only bound during the
updating process by the sounds of things. This is also
partially based on what I read in one of my Access books, the
decision of what edit mode to go into must be made *BEFORE*
typing any data into the form with the form being bound (found
this out via the BeforeInsert Event), and in my situation, the
user is deciding *AFTER* the data is typed into the fields.

That's what I was alluding to in my comment about requiring more
code. thatn driving the mode from a Switchboard Menu form.

The user does know if he wants to add or edit, but the design of
the form causes the user to defer communicating that information
to the program until after he's typed some other information.

If you stay in your single form approach, You could simply lock
all the controls on opening so that the user can only make his
selection of what to do, eg add, edit, delete. exit.

If he wants to add, set the form's recordsource and then unlock
the controls. If it's edit, popup a search form, get the data
then set the recordsource to reflect the user's parameters.
For Delete, I'd load a recordset with the data, then fire a
messagebox asking "Sure? Ok/Cancel" before deleting. .Then you
unbind the form again

 

[Ronald Dodge]

By the way this is looking like, it's looking like I will need 1 VBA
variables per field on the form for what the user types in. I will then
need to use a separate recordset to pull and maintain which record was
inquired on, if any. I already created a separate recordset for
synchronization purposes. This same recordset will be used for that
inquired record purpose as well. Looks as though I will loose the
Pessimistic locking method option due to the bound form issue as this will
be unbound most of the time, and only bound during the updating process by
the sounds of things. This is also partially based on what I read in one of
my Access books, the decision of what edit mode to go into must be made
*BEFORE* typing any data into the form with the form being bound (found this
out via the BeforeInsert Event), and in my situation, the user is deciding
*AFTER* the data is typed into the fields.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Bob Quintal]

Well you know how users tends to resist change if there's too
much of a difference, so that's one such reason why I'm
attempting to keep it the same feel, so as the transition
isn't so rough. Another, users may not know 100% of the time
rather if they need to add a new record or even if they need
to update the record provided it exists. The form would start
out as being allowed for either adding or inquiring. The only
pop up window that there more than likely will be, though not
right away is a name search window for the event they don't
know the ID number. Just trying to be consistent with how JDE
works to a reasonable extent.

In that case, I'd open the form for searching,
To get search values, your control box needs to be unbound
anyway.
You could also enable the addNew button, but I'd make em search
as to not duplicate entries.
Once the user has typed in a search parameter or chose Add New),
you bind the form to the query that returns those records, allow
edits and enable the delete and addnew buttons.

 

[Ronald Dodge]

Well you know how users tends to resist change if there's too much of a
difference, so that's one such reason why I'm attempting to keep it the same
feel, so as the transition isn't so rough. Another, users may not know 100%
of the time rather if they need to add a new record or even if they need to
update the record provided it exists. The form would start out as being
allowed for either adding or inquiring. The only pop up window that there
more than likely will be, though not right away is a name search window for
the event they don't know the ID number. Just trying to be consistent with
how JDE works to a reasonable extent.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Ronald Dodge]

Yeah, I'm using a bound ID field and an unbound ID field, which the user
will only act via the unbound field, not the bound one due to restrictions.
Currently, the bound ID field is visible for design and test purposes, but
prior to the application being released, the bound control will be hidden
and only controlled via code. All other fields are bound, but I'm assuming
that these fields are also unbound when the RecordSource property is set to
a string value of "". I am therefore allowing the user to interact with
these other fields as the RecordSource will only be bound during Inquiring,
Adding, Updating, and Deleting processes.

There most certainly need to be checks in place along the way, though most
of those checks are on a form by form and control by control basis (or
record by record and field by field). I am very much a stickler on data
validations, which is why I had to create my own custom modulated error
checking code within Access to mimic "VB6's CausesValidation property and
Validate event to get around the issue that when doing control by control
(field by field) error checking, it's either always checked or never checked
without this custom code. That's mostly due to how the focus and events of
controls works along with the Cancel variable of both the BeforeUpdate and
Exit events on the controls.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

 

[Ronald Dodge]

Well I have used the UNBOUND form basis for reasons as explained. I still
have a couple of minor things to take care of related to security issues,
but other than that, we will be going into beta test mode come first thing
Tuesday morning.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000