Jer,

>>lets say there are 3 operations ( 10, 20 ,and 30 ) that control the same dimension on a part.
>>rather than having three entries on a grid that when being changed they all need changing individually,
>>the user would see something like <10, 20, 30> in the operaion field of the grid,
>>change it one time and automatically all the records in the (main) table are updated
>>( for operations 10, 20, and 30 in this case).
>>not sure of the best way to acheave these results ( hold record numebrs in display cursor ..? )
>>as the main table holds the operations as ints, and in order to store "10, 20" you would need a char field

I'm not sure where you're going with this. Loading all the related integer values into a display string is fairly
straightforward:

CREATE CURSOR Op_Disp ;
	(Part_ID	I, ;
	 Op_Codes	C(100))
	 
SELECT Part_Id, PADR(ALLTRIM(STR(Op_ID)), 25) AS Op_Id ;
	FROM Part_Dim ;
	ORDER BY Part_Id, Op_Id ;
	INTO CURSOR Part_Codes

m.lnPartId = Part_Codes.Part_Id
m.lcCodes = ""

SCAN
	IF Part_Codes.Part_Id <> m.lnPartId
		INSERT INTO Op_Disp VALUES (m.lnPartId, SUBSTR(m.lcCodes, 2)
		
		m.lnPartId = Part_Codes.Part_Id
		m.lcCodes = "," + ALLTRIM(Part_Codes.Op_Id)
	ELSE
		m.lcCodes = m.lcCodes + "," + ALLTRIM(Part_Codes.Op_Id)
	ENDIF
ENDSCAN

>> 2) there are fields that will be linked to other fields in the same part
>> ( internal dimension poining to the finshed drawing dimension it creates ).
>> this on its own is rather simple. what I was thinking about was holding the record number in a field on
>> the internal dimension. that record number would be the record number of the finished dimension.
>> The problem is that when a part is being changed ( goes through a revision process ) all the information of
>> the old revision needs to be copied exactly so that in the future one could call up all the information as it appeared
>> in an old revision. if this information is copied, then the stored record numbers would be wrong
>> ( new rev pointing to old finished dimension ). The I was thinking about storing an offset value
>> ( the linked record is 10 behind me ), but once again if copied, all the new records will one after another;
>> what if the 9 records inbetween the links where for a different part? Aswell, When there is a revision change
>> I need to be able to quickly identify the differances between the old data and the modified data as the
>> client wishes these variations to be highlighted during the revision change cycle.

>> 3) regarding above, not sure weather to copy old revisions to an obsolete table or keep it in the current one ( identified by the revision number ). When this system is in full use, I expect there to be 1M+ records within 3 years if there is not an obsolete table. not sure which method would be better.


This is not an OOP problem, so much as its a database problem.

First, you are using the RECNO() as the record's prime key. Not a good idea. You would be better off
with a prime key field in the part table and a foreign key and (different) prime key (field) in the part_dim table.
As you add new parts and/or dimension revisions, generate new primekey values. If you ever have to
pack either table and you're using RECNO() as the key, you're screwed... the RECNO() values will change.
With machine-generated keys, your relationships between part and _dim records will be absolute.

With respect to the size of the _dim table, you might want to add a datetime field as a tag for each
part revision. This would not replace the prime and foreign keys you generate. It would be an adjunct.
Such a field could be used to facilitate an automated archive system. Do SQL select against all _dim
records where the Datetime is earlier that some user-configurable date; append those records into an archive table
and then delete the corresponding records from the _dim table.

Regards,
Thom C.