Hi All
I have inherited an old FoxPro database which stores the Parts List for engineering drawings as a long text string.
Some elements of the string are plain text, defining e. g. item number and quantity, other elements are primary key entries for linked data.
Each string represents multiple items separated by the @ sign.
A typical example of the string is given below:
@#a#1#1#8409#0# #F#@#e#2#2#Bl##DIN1543#oZ#5##RSt37-2#1.2# #@#e#3#1#Bl##DIN1543#oZ#5##RSt37-2#3.8# #@#b#4#2#3#12#38# #40#80#F#@
So the first item in this sequence, between the first two @ characters is type a (which means it is a drawing and the following elements should be treated in a certain way).
This is item 1, quantity 1 with drawing pulled from field with primary key 8409 and revision status 0.
Second is type e which is a part and all elements are text.
This is item 2, quantity 2 and the rest is text defining the item, its material and weight.
Third is again type e giving...
Item 3, quantity 1 then loads of general info.
Fourth is type b which is a part but needs to be treated differently.
Item 4, quantity 2 [not sure what the number 3 relates to yet], 12 and 38 pull data from material tables, 40 and 80 are dimensions.
There are five different item types a - to - e that I have seen so far in the extracted data, all which will need to be handled differently by an extract process.
Not sure why the drawing items end with the F character.
I am hoping someone will be able to recommend an approach to deconstructing these string entries, mapping the relevant fields back to the appropriate tables and then restructuring the data in a more meaningful way.
Many thanks
Phil