What you need is a table with fields (desc, qtde, medi, perc), and you need 8 records per "record", that's all. You don't design tables with repeated fields, repetition always is done by storing multiple tuples of data, named records, in a separate table with that substructure.
You should know the principle by now. If you want to store an order you don't have a table order with (ordernumber, customer, orderdate, product1, qty1, price1, product2, qty2, price2, product3, qty3, price3,...), you have two tables, an order table and a table for the different orderitems:
orders: ordernumber, customer, orderdate
orderitems: ordernumber, product, qty, price
Now you can a) have as many order items as you like, b) display all orderitems in a grid simply by setting its recordsource to the orderitems dbf and filter for ordernumbre=x.
You don't need any array for that, you don't need to turn fields of one record into multiple records or array elements.
If you recognize an order as a "record" and think this must go into one table record, then you haven't understood how databases work. If you design your data the usual way, you also can cope with how controls work much easier. I think you're haviong a wrong concept about how data must be stored free of redundancy. The way order and orderitems are designed, the same ordernumber appears multiple times in all data. That's not, what's called redundance because in the order tables it's the primary key value uniquely identifying one order and in the orderitems it's the foreign key, telling to which order the item belongs.
That's how you design such data, and in that way without any further ado items become their own records, easily listed in a grid.
And that#s not all, which is getting simpler. If you want to compute the average percentages of a record of your table structure you need [tt](Inu_perc01+Inu_perc02+Inu_perc03+Inu_perc04+Inu_perc05+Inu_perc06+Inu_perc07+Inu_perc08)/8[/tt] and it even get's complcated if not all 8 fields have a value and the average should be clculated of only 7,6,5,... values. Instead now you simply query [tt]SELECT Avg(perc) as avergaepercentage FROM yourtable2 WHERE key=x[/tt]. There is no SQL command or function calculating an average on a series of fields 1,2,3,4,5,6,7,8. Anytime you write a number in your field names, think about this, you actually want to store repeating things, and that's simplest in an extra table.
Everything is so much easier if you play by the rules. If you design data the way it's intended and supported by controls and query language. Then you also don't struggle and have no hard time with the SQL queries you need. All these database design rules are not there to make it hard on non-professional developers, all the programming tools languages are designed for that design of data, everything "falls into place", if you do it right.
Bye, Olaf.
