> Hi Bernard
>
> Too true. There is no substitute for bad design. Using Search & Replace as a backup for bad design is an excuse not a methodology. It's a bandaid where the adhesive is gong to wear out at some time and fall off!
>
> Absolutely! I well remember a case where someone did exactly what Sergey proposed doing on a whole project that was written using only PRG files (an old FP2.6 application that was being re-written).
>
> They needed to remove a drive letter that had been hard-coded in a number of places. So they did a search on "D:" and replaced it with an empty string. This worked without error and the application re-compiled and ran just fine, accessing the correct drive, until someone noticed that the login screen now said:
>
> "Please Enter Your Passwor"
>
> and then a report was printed with headings like "Total Entere" and "Amount Accumulate" and there were hundreds of other instances of missing "d:" in text strings all over the place.
>
> The idiot (who was actually the IT Director) had not thought about the issue of partial matching or case sensitivity (though of course he should really have replaced "D:\" with "\" anyway). It took the developers DAYS to find and fix all of the occurrences (because he hadn't backed anything up either of course) and so a "10-minute fix" ended up taking several man-days of effort and cost the company a small fortune in lost time and effort.
>
> The problem with global search and replace is that it really IS global and unless you are 100% certain that only the things you want replaced will be (and how do you know that?) it is extremely dangerous.
>
> Even using options like "whole words only" and "match case" can still cause things you do not want touched to be replaced. Unless, of course, you use manual inspection to ensure that only the correct ones are affected and that defeats the whole object of doing it anyway!
>
> Regards
> Andy Kramek
> Microsoft MVP (Visual FoxPro)
> Tightline Computers Inc, Akron Ohio, USAI ran into a situation like the one you describe. In this case though, the programmer had actually written a program that opened the .prg files using FOPEN() and scanned through each line of code applying logic to determine which changes to make. Believe it or not, this program was written entirely in FPD type coding but on a VFP 7 platform (no, it wasn't a legacy program it was new.) Unfortunately, his logic was not very good and his program never worked again - no backups either. I was called in to write the app visually. Can you imagine - writing a program to help you change your program????
Ya know. I think they call it
Visual FoxPro for a reason.
Ken
You shall know the truth - and the truth shall set you free. (John 8:33)