What to do next, please? Preference or logical reasoning?

[Ani]

Hi folks
My Tables are created (with relationship joins) and Ive done my best to normalise them.
Can you please tell me if I should I move on to create forms next or queries? Is it a matter of preference or are there reasons for doing either/or in a certain order? If there are reasons for doing them in order could someone explain please?
Cheers
Ani

 

[pbaldy]

Personally I create forms and reports, and the queries as needed for the forms and reports. I don't know that I would know all the requirements for the queries until I got into the others, but that's me.

 

[Lightwave]

Yep same here I go to form design next note though it is good practice to create a query and source each form from the information of a query and NOT direct from the table. Some forms may use a very small subset of the information in a table and by using a query you can optimize the amount of information coming across a network (that's the reasoning anyway).

So I've slightly contradicted myself there...

I am obviously creating the query immediately before the form but the idea myself and pbaldy are trying to get across though is that we only create a single query prior to form design and that query is specifically written to provide information for a form for which we are imagining.

 

[Ani]

Personally I create forms and reports, and the queries as needed for the forms and reports. I don't know that I would know all the requirements for the queries until I got into the others, but that's me.

Ok Thanks.
Ani

 

[Ani]

Yep same here I go to form design next note though it is good practice to create a query and source each form from the information of a query and NOT direct from the table. Some forms may use a very small subset of the information in a table and by using a query you can optimize the amount of information coming across a network (that's the reasoning anyway).

So I've slightly contradicted myself there...

I am obviously creating the query immediately before the form but the idea myself and pbaldy are trying to get across though is that we only create a single query prior to form design and that query is specifically written to provide information for a form for which we are imagining.

OK, Ive had to read that 3 times but I think I understand, for instance - I could write a query to find a customer (address and all details needed for sending a letter or contacting them) which will then help me create the form. Is that what you mean? Am I understanding correctly?
Thanks
Ani

 

[Lightwave]

OK, Ive had to read that 3 times but I think I understand, for instance - I could write a query to find a customer (address and all details needed for sending a letter or contacting them) which will then help me create the form. Is that what you mean? Am I understanding correctly?
Thanks
Ani

Write the query focusing on the fields you wish to show in the form. Don't worry about singling out an individual record. This will be done alternatively using code often from the preceding form. (the code is often generated automatically for you but it is not a problem to add it later)

Or to put it another way if you are writing a letter to someone and that letter only includes the address of the person if you base the form on the table if that table has lots of further fields in addition to the address Access will in the background drag that information about the place even if you can't see it.
Basing the form on a query means it only drags the fields about the place listed in the query. If it's a beginning application it's probably ok to design straight from the table but I'm just highlighting good practice.

 

[Ani]

Write the query focusing on the fields you wish to show in the form. Don't worry about singling out an individual record. This will be done alternatively using code often from the preceding form. (the code is often generated automatically for you but it is not a problem to add it later)

Or to put it another way if you are writing a letter to someone and that letter only includes the address of the person if you base the form on the table if that table has lots of further fields in addition to the address Access will in the background drag that information about the place even if you can't see it.
Basing the form on a query means it only drags the fields about the place listed in the query. If it's a beginning application it's probably ok to design straight from the table but I'm just highlighting good practice.

Thank you. I think I can see what you mean. For some of the forms I envisage, it will probably help to keep the forms precise, to use a query.
The db is only going to be used by myself, I am running a service that is really more of a hobby than a business. However I want to learn how to develop the db as part of my hobby and there's not much point doing something improperly, is there!
Cheers
Ani

 

[gemma-the-husky]

i am sure you find you will develop both together

you need forms to interact with your data. your forms will require queries as their record source. as you process the data you will find you may need additional "action" queries, to process the data - update, append and delete queries

you may even decide your table design needs modification.

 

[Ani]

i am sure you find you will develop both together

you need forms to interact with your data. your forms will require queries as their record source. as you process the data you will find you may need additional "action" queries, to process the data - update, append and delete queries

you may even decide your table design needs modification.

Yes! As I have been playing with designing forms there have been a few fields Ive had to change, Im just worried now that I havnt missed something that cannot be changed at a later date. The normalisation explanations have helped enormously though. I think that perhaps I should make a back up copy each time I attempt a new stage.
Cheers
Ani

 

[Ani]

Hi Guys
I have followed good practice and created forms, from queries. Now this may be a little silly to you because you know what you are doing from beginning to end.
I do not know what exact queries I will want from all my tables so I created a query for each table, with all fields, then created the forms.
Now the forms should be easy to use to enter the data into but how do I tell access to open a new blank form? I only have one set of data in the tables, so that's all that shows up, Im guessing because I created a query, so of course the only thing it can show is 1 form with one set of data.
Or do I have to do this another way?
Cheers
Ani

 

[pbaldy]

You can either set the Data Entry property of the form to Yes or use the Data Mode argument of OpenForm.

 

[Ani]

Thanks Paul. I dont know what 'Data Mode' argument is. I will look that one up.
Ani

 

[pbaldy]

No problem Ani. Help on OpenForm will clarify it for you.

 

[Ani]

OOH I just found an OpenForm explanation. That looks really useful. I may just keep it simple for now while Im experimenting though and change the data entry to yes.
Thanks again Paul.
Ani

 

[pbaldy]

Happy to help! I often use the same form for data entry and edit, using that argument to control the mode, along with the wherecondition argument to restrict to the desired record to edit.

 

[Ani]

Happy to help! I often use the same form for data entry and edit, using that argument to control the mode, along with the wherecondition argument to restrict to the desired record to edit.

That sounds scary! LOL
Errrm I may have to go back to form or query design. Changing the data entry to yes doesnt give me a blank form or the option to click the arrow to open a new one?
I have saved and re-opened.
I have no idea where Ive gone wrong now!
Ani

 

[pbaldy]

It sounds like the query is read-only. Does it allow you to enter a new record in it?

 

[Ani]

No...I get pinged at!

 

[pbaldy]

You've got something making it read-only:

http://allenbrowne.com/ser-61.html

http://support.microsoft.com/default.aspx?scid=kb;en-us;328828

 

[Ani]

just reading the allenbrowne one now. Will try the other link too. Thanks Paul.
Ani