UNIX for Dummies Questions & Answers

Most SQL tables have a key field or fields. Normally the key field would be used to identify and match the record to determine if it has changed. But from your requirement, this is not what you are looking for.

Also, normally SQL queries do not guarantee the order of records unless the order by clause is used. So, without order by, the same query executed twice could, theoretically, return the same records in two totally different orders.

True. Even if the files are not ordered it would be possible to pipe them through "sort" (man sort) to get them sorted prior to searching them. This would limit the search-effort too, because at some point one could be sure that no matching record will follow.

bakunin

Hey bakunin n kahuna
thanks a ton
i think i got to change my codes n look for other approach

as pointed by both of u rightly
"Also, normally SQL queries do not guarantee the order of records unless the order by clause is used. So, without order by, the same query executed twice could, theoretically, return the same records in two totally different orders."

there is no guarantee that order of records would be same ...

so simply matching row wise ... would not generate desired result

ll get back with new set of codes

Dana, I don't think your problem is in your input files - your problem is in your approach. You should *analyze* your requirements, make a plan how to implement them and *only then* write a program. The real knowledge you need to acquire is not "do i lay a brick here or there?" but "how does the house i want to build look like?".

Lets start over: you tell us, what you want to achieve and which data you have got. Then we help you develop a plan to derive the data you want from the data you have. Finally - but only after this step - we implement the plan into real existing software.

Sorry for becoming a little theoretical here, but you are having a very common problem among system administrators here: just because a program (yes, a script is a program like every other) might be short doesn't mean the way software engineers (real software engineers, not the itsy-bitsy mouse-pushers with their 5D - 6GL - graphical - object- blabla - tools) organize their work:

understand your goals (the goals of your customer)
organize what you have got to work with
define your requirements
make a plan to get from where you are to where you want to be
only then put this plan to work by writing the software

If you read the whole thread from the beginning it is like you ask how to change the tires of your car. It turns out, though, that your problem is not a tire, but your car doesn't work any more for reasons unknown and you just *think* that might have something to do with the tire needing to be changed. So you don't need to know hoe to change the tire but you need to find out the reason why your car won't go anymore - maybe its the tire, but maybe its something completely different. Lets get back to this step otherwise you might end up with a car with four brand new tires which still won't go because the gearbox is broken.

bakunin

What a thread !
Interesting read and as bakunin has suggested it isn't the tire.
My impression from reading the thread is that Dana's kinda asking for a "dynamic" comparrison (if there is such a thing).
Especially when Dana mentions: But I still consider myself a novice so I'll end my rant here.

Cheers,
Cameron D)

did you try the solution I had posted ?

bakunin -
just asking this question out of curiosity though this would not add any value to thread ?

So, what is the difference that you were trying to express between the software engineers and the real software engineers ?

I didn't understand when you said about the itsy-bitsy thing

Again - this question is only out of curiosity.