UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
3 Pages V  1 2 3 >  (Go to first unread post)
   Reply to this topicStart new topic
> Page Control Forms, Access 2016    
 
   
mmchaley
post Apr 8 2020, 02:30 PM
Post#1



Posts: 58
Joined: 26-April 16



Hello all,

I am looking for thoughts and opinions on using the page control option.

I am having a work process that is getting beyond my single form. I am thinking about using page controls to define the work flow.

My question is, is it better add the field controls onto the Page Control, or is it better to create a separate form and add the form to the page control?

Thanks much,
Mark

How do you edit the title? Should be Page, not Age frown.gif
This post has been edited by GroverParkGeorge: Apr 9 2020, 08:38 AM
Reason for edit: Post Title
Go to the top of the page
 
Doug Steele
post Apr 8 2020, 02:46 PM
Post#2


UtterAccess VIP
Posts: 22,281
Joined: 8-January 07
From: St. Catharines, ON (Canada)


I've always found it easier to use a separate form as a subform on the page.

--------------------
Doug Steele, Microsoft Access MVP (2000-2018)
Personal webpage
Microsoft profile
Co-author: Access Solutions: Tips, Tricks, and Secrets from Microsoft Access MVPs, published by Wiley
Co-author: Effective SQL: 61 Specific Ways to Write Better SQL, published by Addison-Wesley Professional
Technical Editor: Access 2010 Bible, Access 2013 Bible, Access 2016 Bible, all published by Wiley
Technical Editor: SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL, 4th Edition, published by Addison-Wesley Professional
Go to the top of the page
 
tina t
post Apr 8 2020, 02:50 PM
Post#3



Posts: 6,601
Joined: 11-November 10
From: SoCal, USA


QUOTE
My question is, is it better add the field controls onto the Page Control, or is it better to create a separate form and add the form to the page control?

i assume you're talking about a Tab Control, which has "pages". as long as you're working with one table, recommend you don't use a second, separate form - even as a subform. if you do, you'll run into update issues. better to put the bound controls directly on the tab page(s) where you want them.

and btw, how many fields are in your table? while there is no set maximum number of fields that should be in a table, it's a general rule of thumb that if a table has more than 30 to 40 fields, it's a warning sign that the table may not be normalized.

hth
tina

EDIT: well, Doug is more experienced and skilled than me, by far, so i wouldn't presume to contradict him. :) @Doug, am i thinking of something else, when i think about write conflicts on the same record in a form and a subform?
This post has been edited by tina t: Apr 8 2020, 02:53 PM

--------------------
"the wheel never stops turning"
Go to the top of the page
 
projecttoday
post Apr 8 2020, 03:12 PM
Post#4


UtterAccess VIP
Posts: 12,205
Joined: 10-February 04
From: South Charleston, WV


I would say a tab control is fine if all you want is to organize or separate controls on a single-record form.

--------------------
Robert Crouser
Go to the top of the page
 
mmchaley
post Apr 8 2020, 03:21 PM
Post#5



Posts: 58
Joined: 26-April 16



Yes, Tab Control ( didn't want to say tab control as some may confuse that with tab order)

Thanks for the input - Wonderful thing about access, no two people have the same experience with it.

I currently have 68 fields in the table - some of them are related, like address accounts for 5 alone

I will have to think on how i would break my table down as it has expanded in the number of fields
Go to the top of the page
 
projecttoday
post Apr 8 2020, 03:47 PM
Post#6


UtterAccess VIP
Posts: 12,205
Joined: 10-February 04
From: South Charleston, WV


Sixty-eight fields could be a sign of incorrect design or maybe not. Do all of these fields pertain to the subject of the table?

--------------------
Robert Crouser
Go to the top of the page
 
Doug Steele
post Apr 8 2020, 04:22 PM
Post#7


UtterAccess VIP
Posts: 22,281
Joined: 8-January 07
From: St. Catharines, ON (Canada)


Definitely agree with Robert: 68 fields in a single table is almost always a sign of incorrect normalization.

Tina: You may be right, but I think I'm being vindicated! laugh.gif

--------------------
Doug Steele, Microsoft Access MVP (2000-2018)
Personal webpage
Microsoft profile
Co-author: Access Solutions: Tips, Tricks, and Secrets from Microsoft Access MVPs, published by Wiley
Co-author: Effective SQL: 61 Specific Ways to Write Better SQL, published by Addison-Wesley Professional
Technical Editor: Access 2010 Bible, Access 2013 Bible, Access 2016 Bible, all published by Wiley
Technical Editor: SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL, 4th Edition, published by Addison-Wesley Professional
Go to the top of the page
 
FrankRuperto
post Apr 8 2020, 04:39 PM
Post#8



Posts: 980
Joined: 21-September 14
From: Tampa, Florida USA


We don't know yet. It depends on what's being stored in the table. Maybe the entity has many attributes that belong together. As long as the table is normalized then there's really no rule of thumb as to how many fields constitutes too many. Since OP mentioned a workflow, maybe its a process that involves many steps that would live better in a child table and use a subform?
This post has been edited by FrankRuperto: Apr 8 2020, 04:52 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
Doug Steele
post Apr 8 2020, 04:48 PM
Post#9


UtterAccess VIP
Posts: 22,281
Joined: 8-January 07
From: St. Catharines, ON (Canada)


I think you'll find that the majority of us old timers claim 20 fields in a properly normalized table is unusual, Frank.

--------------------
Doug Steele, Microsoft Access MVP (2000-2018)
Personal webpage
Microsoft profile
Co-author: Access Solutions: Tips, Tricks, and Secrets from Microsoft Access MVPs, published by Wiley
Co-author: Effective SQL: 61 Specific Ways to Write Better SQL, published by Addison-Wesley Professional
Technical Editor: Access 2010 Bible, Access 2013 Bible, Access 2016 Bible, all published by Wiley
Technical Editor: SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL, 4th Edition, published by Addison-Wesley Professional
Go to the top of the page
 
FrankRuperto
post Apr 8 2020, 05:18 PM
Post#10



Posts: 980
Joined: 21-September 14
From: Tampa, Florida USA


I think it all depends, I've seen some very wide flattened tables in data warehouse applications. I can think of several objects in this world that have many attributes, each having multiple options, e.g. house, vehicle, etc. There is such a thing as over-normalizing, and sometimes tables are intentionally denormalized to improve performance and simplify complex queries, but maybe that's not the OP's usecase and he put a bunch of fields in one table in order to use one main form for all of them?
This post has been edited by FrankRuperto: Apr 8 2020, 05:26 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
tina t
post Apr 8 2020, 08:34 PM
Post#11



Posts: 6,601
Joined: 11-November 10
From: SoCal, USA


QUOTE
Tina: You may be right, but I think I'm being vindicated!

hi Doug! :) not sure what you mean, hon. my comment was sincere, and my question was real. was i thinking of a similar, perhaps, but different scenario re write conflicts? as for number of table fields, i agree with both you and Robert, as i mentioned it in my first post. :) tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
Doug Steele
post Apr 9 2020, 07:34 AM
Post#12


UtterAccess VIP
Posts: 22,281
Joined: 8-January 07
From: St. Catharines, ON (Canada)


Sorry for being flippant, Tina.

Yes, you likely will run into contention issues having multiple forms trying to write to the same row in the table. However, given what we're hearing about the design, my suspicion is that the data should be written to multiple tables, so that contention shouldn't be an issue.

Stay well!

--------------------
Doug Steele, Microsoft Access MVP (2000-2018)
Personal webpage
Microsoft profile
Co-author: Access Solutions: Tips, Tricks, and Secrets from Microsoft Access MVPs, published by Wiley
Co-author: Effective SQL: 61 Specific Ways to Write Better SQL, published by Addison-Wesley Professional
Technical Editor: Access 2010 Bible, Access 2013 Bible, Access 2016 Bible, all published by Wiley
Technical Editor: SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL, 4th Edition, published by Addison-Wesley Professional
Go to the top of the page
 
tina t
post Apr 9 2020, 01:51 PM
Post#13



Posts: 6,601
Joined: 11-November 10
From: SoCal, USA


you too, Doug, thank you! :) tina
This post has been edited by tina t: Apr 9 2020, 01:52 PM

--------------------
"the wheel never stops turning"
Go to the top of the page
 
mmchaley
post Apr 10 2020, 11:50 AM
Post#14



Posts: 58
Joined: 26-April 16



The table that is 86 fields is for tracking quotes. I have things that are specific to each individual quote like project address, quote number, owner's quote number, project name, dates (I have 6 dates I need to track for each quote) bonding info (6 fields), Then i have a few long text fields for scope narratives, project risks, and general comments.

I could break it apart, but as I only add about 200 records a year, and can archive every 3 years it is not too cumbersome.


So, the initial question of adding field controls directly to a Tab Control Page or creating a form then adding the form to a Tab Control page.. I only have 2 thoughts so far and they are 100% opposite. I would like to hear more from those who have used this feature more.

Thanks,
Mark
Go to the top of the page
 
tina t
post Apr 10 2020, 03:30 PM
Post#15



Posts: 6,601
Joined: 11-November 10
From: SoCal, USA


well, a lot of developers use tab controls and subforms for various scenarios. probably not a lot of experienced developers design tables with 86 fields, so the issue doesn't really come up. that may be why you're not getting a lot of answers.

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
mmchaley
post Apr 14 2020, 04:13 PM
Post#16



Posts: 58
Joined: 26-April 16



Even if i were to break the table down, I still have the same question. It is a matter of work flow for what I am doing, not the number of fields I have in a single table.
Go to the top of the page
 
projecttoday
post Apr 14 2020, 04:39 PM
Post#17


UtterAccess VIP
Posts: 12,205
Joined: 10-February 04
From: South Charleston, WV


Tina is probably right. Tab controls really aren't that common.

Your form is only for one table. If you put a form on each tab of the tab control you would have multiple record sources based on the same table which you would then have to navigate to the same record once the user opens the form.

Just have one form based on one record source. Drop a tab control on it. Put whatever fields you want on page 1. Put whatever fields you want on page 2. Put whatever fields you want on page 3. On so on.

--------------------
Robert Crouser
Go to the top of the page
 
mmchaley
post Apr 14 2020, 05:17 PM
Post#18



Posts: 58
Joined: 26-April 16



Thank you - that helps, I was going about it backwards and didn't realize it.
Go to the top of the page
 
projecttoday
post Apr 14 2020, 06:02 PM
Post#19


UtterAccess VIP
Posts: 12,205
Joined: 10-February 04
From: South Charleston, WV


Okay. Let us know how it goes.

--------------------
Robert Crouser
Go to the top of the page
 
FrankRuperto
post Apr 14 2020, 08:12 PM
Post#20



Posts: 980
Joined: 21-September 14
From: Tampa, Florida USA


Can you provide us your table design?.. Hopefully the field names in your 86-field table are descriptive, then we can analyze it and make better suggestions.
This post has been edited by FrankRuperto: Apr 14 2020, 08:13 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
3 Pages V  1 2 3 >


Custom Search


RSSSearch   Top   Lo-Fi    30th May 2020 - 09:29 AM