Object Source / Record Source

[Shakeel Ahmad]

Hello

I have created a database regarding the School System.

I have created three forms (one form and two subforms)

one main form is (Students) where i enter student's name, father's name,
phone, address etc.

now on the main Student form i want to place a subform. But the thing i want
to know is:

I want to make two buttons on my main form (Fees) and (Progress).. because i
have two subforms (sbffees and sbfprogress)

now the record source of subformbox should be controled with these two
buttons. when i click the ( Fee) button the Source Object should be
(sbf-fee)
and when i click the (Progress) button the Source object of the subform
should be (sbfProgress)

How can i do this..... and Advance thanks for the repliers because i am
sure, i will get from here what i need.
--
Best Regards

Shakeel Ahmad

(e-mail address removed)
www.groups.yahoo.com/group/islam-the-final-truth
www.geocities.com/shakeelahmad_79

 

[Franck]

I have a easy solution for you

first lets take the subforms
subform fee
subform progress

now for example you want subform fee shown by default (could be
progress it doesnt matter just choose one)

now create the 2 subforms
name them with easy recognizable names.
put subform progress visible = false (so its not shown on first
opening)
then superimpose both subforms. now create code for both button and on
the Fee button
code it so it does like this
subformprogress.visible = false
subformfee.visible = true

and do the inverse for the progress button.

both buttons will only make disappear the other form and show his.
just make sure your link between student table and subform are
correctly made and nothing else than visibility will be touch

 

[Franck]

oh yeah i forgot, you could even do a update of the subform with vba
code when it show back the form
dont remeber the code exactly but should be
me.subform.update

 

[Shakeel Ahmad]

Thanks for your quick reply.

I am going to try it.

 

[Larry Linson]

Alternatively, you create the Forms to be embedded in the Subform Control,
and your buttons simply reset the "SourceObject" of the Subform Control to
the proper form. It will be simpler if the main-form Field you specify as
LinkMasterFields for the Subform Control matches a field that you will
specify as LinkChildFields (whose name is the same in the RecordSource of
each of the Forms that you'll embed in the Subform Control).

Larry Linson
Microsoft Access MVP

 

[Franck]

Alternatively, you create the Forms to be embedded in the Subform Control,
and your buttons simply reset the "SourceObject" of the Subform Control to
the proper form. It will be simpler if the main-form Field you specify as
LinkMasterFields for the Subform Control matches a field that you will
specify as LinkChildFields (whose name is the same in the RecordSource of
each of the Forms that you'll embed in the Subform Control).

Larry Linson
Microsoft Access MVP

ya but that would reload the subform each time.
i dont really like reloading and reloading stuff. i prefer load once
and switch betwwen. Unless your computer have like
16meg ram

 

[Larry Linson]

ya but that would reload the subform each time.
i dont really like reloading and reloading stuff. i prefer load once
and switch betwwen. Unless your computer have like
16meg ram

Perhaps you did not see the first word in my response? "Alternatively"
means I am offering an alternative for the user to consider.

One would have to do more performance testing that is likely warranted to
determine whether changing the Source Object performs less well than the
overhead of having two Subform Controls, each with a Form, both
synchronizing when the main Form's Record changes.

I've done this both ways, and couldn't see any performance difference with
the data I was dealing with.

Larry Linson
Microsoft Access MVP

 

[Franck]

try with over 100,000 records with joints everywhere, but i have to
admit it's rare doing this with that number records, the person
needing to do this should change to sql before reaching millions of
record (+1 gig database). i saw something like this in a POS system we
had to use multiple access database linked tables in that case your
solution is better because the invisible thing was to heavy on the
system we had 7 subform with huge record sets each loading them all at
begining was causing a good 5 minutes waiting line before the form
completly loads up. it was better to load it up and load only 1
subform and change the record source only.

 

[Larry Linson]

try with over 100,000 records with joints everywhere, but i have to
admit it's rare doing this with that number records, the person
needing to do this should change to sql before reaching millions of
record (+1 gig database). i saw something like this in a POS system we
had to use multiple access database linked tables in that case your
solution is better because the invisible thing was to heavy on the
system we had 7 subform with huge record sets each loading them all at
begining was causing a good 5 minutes waiting line before the form
completly loads up. it was better to load it up and load only 1
subform and change the record source only.

There are many Access / Jet databases running very successfully, and with
adequate performance, with hundreds of thousands or millions of records.
There are also Access / Jet databases running very successfully, and with
adequate performance, with multiple backend databases containing their
linked tables. It is, precisely, those situations where very careful
planning / testing / experimentation has to be done for performance.

You are correct, however, that those are rare, and I do not typically offer
advice that will cause extra effort for the implementer in what I expect to
be the "normal" case.

In fact, in such cases, I would most likely not use the standard
LinkMasterFields and LinkChildFields to synchronize, but would test to see
if performance were better if I created a specific query to apply to the
Form embedded in the Subform Control so that the database engine would do
the data manipulation (it is likely to be far more efficient at
selecting/returning data than Access is at sychronizing).

And, in my experience, issues such as logging, reliability, and
recoverability most commonly have much more to do with the decision to use
a server database than volume of data or performance.

Larry Linson
Microsoft Access MVP

 

[Franck]

it's there that SQL server can come to the rescue as the backend and
either Access/Vb/C as frontend.