Jim,

I agree on all but one of your points because I have finally found a good use for INDEX ON UINQUE

I have a system that receives a daily text file containing ATM/POS transaction 1.4 - 2.0 million transactions and 372 bytes wide and this file will eventually grow beyond VFOX's size constraints. As part of the checking of the file (ie header contains file date footer contains # of records) I check for new customers, new transaction status etc, this file is NEVER changed (no adds or deletes allowed) the file is converted to VFOX and processing is preformed on it only if all the data elements are in the customers data files. If not the Customer recieves an exception report and after the customer enters the required data the execption systems runs again until they get it right. As typical with users this is rarely a one pass system... So the time lost indexing is very quickly made up in the 45 seconds of checking..

I never thought I'd use UNIQUE but boy will I cry if it goes bye-bye


Thanks

JohnP
INFOLynx




>>>1: Inheritence has to be the single most commonly misused feature of all OO languages.
>>
>>Sure can be, but I'd rather see it abused than not at all :-) Can you give a good example?
>
>Ok, here's my favorite (is that the reight way to say that?) abuse of inheritence. I create a form class, then I subclass it and put buttons in it, and I subclass it again and put different buttons in it etc.. This would be mych better handled by using a factory pattern that would create teh required buttons at the Init of the form object.
>
>Create an Save button class and then subclass it to provide differing code in the click event. Much better to have one Save button that calls some other method of some other object for the behavior.
>
>Thereare many many mroe possible examples.
>
>>>4: Filtered indexes, are often used where they are not necessary. The same result can be obtained using SQL without the overhead of having an extra index tag around all the time.
>>
>>I have never used a filtered index in VFP. I cannot see the point.
>
>
>I used them a few times. One was for a system for a Bank's CD renewal operation. Each operator was assigned to a specific geographical region so it was pretty fast to have 6 filtered indexes one for each region instead of selecting the regions through a filter or select command.
>
>>>6: PUBLIC variables are often used in situations where they are totally not required.
>>
>>Like...hmmm...in ALL situations? My only disagreement with you on this is with some objects. Like I might want to fire up a public instance of Excel the first time I need it and not in my startup code.
>
>Again, If the sapplication needs to ahve access to teh excel object from all over the place then create the variable in the startup program;
>
>

>* Startup program
>PRIVATE oExcel
>oExcel = NULL
>

>
>Then when you need it you can;
>
>

>IF TYPE("oExcel.Name") <> "C"
>   oExcel =- CreateObject("Excel.Application")
>ENDIF
>