Making a DB for a friend who repairs cars, he would like a layout to display 12 lines down and to have these fields in each line,

"Part Description", "Price", "Cost" & "Profit" which would mean 12 fields for each totalling 48 (may even want more).

I've searched FMForums and numerous Google searches and everytime I get the same old answer, make your DB using Customers,

Invoices, Products and Line Items, this is just dandy if you sell Widgets & Dingdongs, just put them into the Products Tables and

all's fine, popup and ID Number and there it is. But here were talking about 1000's of car parts. My question is, should I be

creating separate fields or is this one time Repeting Fields should be used or is there another option I'm missing.

Many Thanks.

Portals is what you need rather than repeating fields.

only thing is you need a good relationship why you get the same answers .

rather than a popup you can do a search using global field to start & end search using function

Position(text;searchString;start;occurrence)

hope that helps ya

this is just dandy if you sell Widgets & Dingdongs, just put them into the Products Tables and all's fine, popup and ID Number and there it is. But here were talking about 1000's of car parts.

... and you will get the same old answer from me. You need to use proper structure so these '1000's of car parts' are individual records in the Products table and are selected and added to your LineItems table to display in a portal identical to what you have above.

I am not sure where the 48 comes from ... I see 12 Categories down the left side. Look at 'Belts & Hoses' - what if someone needed the fan belt AND the radiator hose replaced? Each part should be a line otherwise you cannot list the prices of different items. If each part is assigned a Category then the portal can be sorted first by Category and then alpha by part. To select a part to insert, you can use conditional value list where User selects Category then the parts list itself (in the next pop-up) will only display parts for that category.

But here were talking about 1000's of car parts.

What difference does that make? You still need to select one of the 1000's of car parts - whether you are using individual fields, repetitions of a field or (as you should) individual records to register each part sold.

The idea behind having a separate record for each product sold is that records can be easily found, sorted and grouped. IOW, the recorded information can be presented in a variety of meaningful manners. Otherwise you are merely archiving data for no apparent purpose.

The user interface - including the problem of selecting a product - needs to be solved separately, without compromising the underlying data structure.