Hi Cetin

It's a bummer. I've converted all the source data to the tables. Counting the no. recs for the thermo. as I said, is now much quicker with RECCOUNT(). However, creating the Journery records (there are several of these per route, each starting at different times during the day) is taking forever! - seemingly as long as before and possible longer! I don't understand it. There are some 186000 recs to process, mind you but I see no improvement uin speed.

Cheers

Terry
>Hi Cetin
>
>Thanks a lot for the worked example. Some neat ideas. I've got my "interim" soln. working almost but, considering your ideas, I think it would cut out a lot of the complexity of my code if I split the generic groups into different tables and work with each individually. At the moment, the Operator details (Qp & QQ recs), for example, follow the Stop recs (QL & QB). There are also QA recs that I need to ignore. So afetr the QA & QLs are exhausted, I keep my place in the file (txt or dbf) and follow on checking for the operator dets. If I split the file into operator and stops tables then I can just scan through each with confidence.
>
>At present I have to "skip" over unwanted recs with other codes, in the logic. With the new scheme I can just exclude them with the filters - "cut the wheat from the chaff", when I append from.
>
>I don't think I'll go to the extent of indexing and relating them though - each QB has a matching QL so I'd have to switch tables every other rec. Also, the QP & QQ are related but have no keys in common (QP is essential dets while QQ is address and stuff)
>
>The "stops on route" file has several QO (origin - journey start), followed by a series of QI (interim stops), followed by a QT (terminus). They have no keys in common. Each line features a stop ID (with county) followed by its arrival and dep. times. Also, each set of these is preceded by a QS - Journey desc rec. So its the sequence of reading them that gives the relation (for each QS I create a journey, then create its stops from the following QO, QI, QT recs).
>
>Anyway, I'l have fun with this and let you know of the speed improvements.
>
>Thanks again
>
>Terry
>
>I may relate the
>>>Terry
>>
>>Nice to hear it was of help. I'm not sure about if you noticed the 'tip' burried in 'tip'. You can filter during append. That's for example you can get your 2nd sample txt file's QB and QL lines into 2 separate cursors at once, instead of checking later (thus faster reccount() vs count):
>>
>>Consider this:
>>

>>Text to m.lcSample noshow
>>QB39003800Ipswich:Start BusStop
>>QL39003800691148621001 town1
>>QL39003800691149621003 town2
>>QL39003800691149621005 townEnd
>>QB39013800Ipswich:Start BusStop2
>>QL39013800691148621001 town1_2
>>QL39013800691149621003 town2_2
>>QL39013800691149621005 townEnd_2
>>EndText
>>lcFile = "myBusStops.txt"
>>StrToFile(m.lcSample,m.lcFile)
>>
>>create cursor bParent (code c(2),f1 c(4),f2 c(4),description c(50))
>>create cursor bChild (code c(2),f1 c(4),f2 c(4),lat c(6),lon c(7),town c(10))
>>select bParent
>>append from (m.lcFile) for code='QB' type SDF
>>? reccount(),"Parent"
>>select bChild
>>append from (m.lcFile) for code='QL' type SDF
>>? reccount(),"Child"
>>index on f1+f2 tag linker
>>browse nowait
>>select bParent
>>set relation to f1+f2 into bChild
>>browse

Cetin