Ok, I'm building a parts inventory file that has the ability to track multiple quotes form different vendors for each part.

I would like to be able to show the price breaks for any given quote: (i.e if you buy qty 0-10 you get this price,10-20 gets this price, etc)

Because these vendor quotes are already in a separate related file and given that only 500 out of 10000 records will use this feature, my feeling is that a third related file is a waste / unnecessary burden . I was thinking perhaps a repeating field for the each of the breaks. The question is , however, how do we extract the right price when the user is entering the part into a PO.

I was thinking it might also simplify things if we designated one particular repetition as the default (which would be good since we have economic order qty defined as well). But even then I am not quite sure how to make the repetition show through....

It can be done, but I have to say upfront that I wouldn't recommend it. You seem to be saying that using a relational structure will be a greater burden than using repeating fields, whereas in almost all cases, the reverses is true. Relational capabilities were introduced so that the extraordinarily burdensome and inflexible structures based on repeating fields could be replaced with a simple, elegant and self-sustaining mechanism.

Having said all that, the default value in a repeating field is the first (ie if you don't specify a repetition, the value returned is always the first) - and it is possible to use the GetRepetition( ) function to access a specific repetition according to criteria which can be determined dynamically (by the inclusion of additional functions/calculations to set the parameters for GetRepetition( )).

By comparison, however, a simple little table of price breaks will be easy to create, easy to update and easy to reference, will gather all the price-break information together in one place (rather than distrubutong it throughout your PO data) and will not present all the awkward dillemmas when importing/exporting data, nor when a new set of price-break configurations are introcuced (you've just need to create a few extra records in the table, rather than building a lot of new repeating fields and code to manage them).

Just supporting CobaltSky's recommendation -- never, Never, NEVER use repeating fields!

OK, that's not quite true; I have found occasion to use repeating fields occasionally, but I can almost guarantee that if you use repeating fields instead of a related file here, then you will run into trouble.

One of the reasons you're almost certain to have problems is that when it comes time to upgrade the system, you'll be stuck with the "dinosaur" of repeating fields. Relationships can be adapted much more easily. Save yourself the eventual headache; use a related file.