Max form width too small

[VBAWTB]

I have to create a form with 39 fields to fill across...I can only fit 20...any ideas? I'm really stumped..

 

[Galaxiom]

Having to scroll sideways s not an ideal form strucutre.

I assume you are looking for a datasheet view. Instead use multiple rows of controls in Continuous Forms mode.

 

[gemma-the-husky]

what are the fields? do they have to be all shown together?

loads of ways to manage display, but obviously you are limited by screen width. text fields do not have to be full width - you can "expand" any field simply.

 

[speakers_86]

Consider using tabs to group similar fields together.

 

[VBAWTB]

Galaxiomathome... no I want a form view. Will that still work?

Gemma-the-husky... yes they need to all be together for optimal data entry.. My text boxes are as narrow as they can be (if that is what you mean). If there is loads of ways to set this up properly and with speed of data entry in mind, I am open to any ideas =]. I am not sure where to go with this..

speakers 86... I though about that, but there isn't any way to really break them up... it's all pretty much one group (currency data for the month), plus clicking on tabs during data entry would slow things down a bit. Thanks though!

Any ideas on how to set this form up would be greatly appreciated! Please Help!

 

[gemma-the-husky]

well 39 fileds sounds a lot - are you sure the data is normalised properly? what ARE all the fields?

if they have to be on 1 form, you need to lay them out differetly. i think most of use would probably use tabs/pages something like that

assuming you have a continuous form, consider showing fewer controls on the main form, and maybe open another form the other entries. might not be exactly what you want, but you have to do the best you can.

 

[missinglinq]

As Dave has suggested, 39 Fields is a lot for a single RecordSource, the basis for a Form. Most experienced developers will tell you that a 25-30 Fields is usually the maximum number for a RecordSource that is part of a Normalized Database.

As far as optimum data input is concerned, frequently utilizing a Form/Subform scenario will allow for optimum input to more than a single Table.

Linq ;0)>

 

[VBAWTB]

Gemma-the-husky... thanks for your fast reply! The fields are a listing of monthly expenses that my client keeps track of for his Subway stores. I believe it is normalized correctly. Speed and efficiency are key to my client...tabs I think would bug him to much...can you work the fields downward in stead of across? Only one row would be entered per month.. unless he decides to enter more than one store... :/

 

[Mr. B]

If you are going to use your form in Form View you can place controls (fields) any where on the form. With your form in design view, just try moving your controls to the desired location.

 

[VBAWTB]

missinglinq... yes I realize that is a lot for a single recordsource... it is a single table. Here is the list

Accounting
Attorney
Auto-Gas
Bank Service
Cash Over
Condiments
CC Merchant Fees
Dividend Checks
Employe Incentives
Equipment
Equipment Rental
Insurance- Wrk Comp
Interest Earned
Jason's Buy Out
Licence/Permits
Linen (Cintas/WE Cleaners)
Loan- Grant
Loan- Equipment
Loan-Build Out
Local Advertising
Office Supplies
Paper Product
Cell Phone Managers
Phone - Store
Rent
CAM Charges
Repairs/Maintenance
Royalties -DAI
Royalties-SFAFT
Royalties -Additional
Savings Account
Small Wares
Supplies
Uniforms
Utilities-Electric
Utilities-Gas
Wages

(pulled off of Excel)

They are all related, only one number(currency) per item is needed, and it does not need to be updated or edited. Is this normalized? Is there a better way to do this?

 

[gemma-the-husky]

things like these should be in a continuousform/subform and will display downwards.

this data structure is not normalized.

eg what happens if you get another analysis code - you have to adjust your form to 40 columns, i take it.

 

[VBAWTB]

Mr. B.. Thanks! I will see what I can come up with... does anyone else think this may not be normalized, the way I have it set up?

 

[VBAWTB]

sorry gemma-the-husky....you posted while I was writing my last post... I see what you mean..my client says the list won't ever change, but I should set it up so that it CAN be changed... I will have to change some tables around, but I think this will be the better way to go, especially when I start querying data for reports. Thank You!

 

[gemma-the-husky]

sorry gemma-the-husky....you posted while I was writing my last post... I see what you mean..my client says the list won't ever change, but I should set it up so that it CAN be changed... I will have to change some tables around, but I think this will be the better way to go, especially when I start querying data for reports. Thank You!

but what this means is that rather than have columns/fields for expenses in a table you should have this structure

1. a table for expense categories, which includes all the 39 cost centres

2 another table for expenses, which includes the expense categoryid, (as above), then the date, amount, reference no, etc,etc

now to get a total expense, you link table1 to table2, and sum all the expenses in table2, in a query.

now, when you make a form/report from THIS query, you get the expenses, and expense values listed vertically.

But i doubt if this is anything like you have, so this will need some work.

 

[VBAWTB]

Uh..no but I have another couple of tables that handle food supplies and it is set up like you just mentioned... I don't have any queries set up yet though. Are you saying to create the query first and then create the form from the query?

 

[speakers_86]

Of course thats what gemma means.