> >
> > One more advise: when dealing with tables/cursors - try to use fully qualified fields' names, that is use the alias names with them, i.e.
> >
> >

m.CustAddr = CUSTOMERS.Address1 + CUSTOMERS.Address2
> > && instead of
> > SELECT CUSTOMERS
> > m.CustAddr = Address1 + Address2

> > First off, it would save you a line of code (no need to SELECT CUSTOMERS).
> > Second, it makes your code independent of the currently selected work area.
> >
> > Moreover, I would recommend using the explicit reference to the pertained table's alias every time, everywhere! For instance:
> >
> >

REPLACE CUSTOMERS.Inception WITH DATE(), ;
> >         CUSTOMERS.Category WITH "New" IN CUSTOMERS

> > this would save you - and VFP - from a lot of confusions (and therefore - program errors) over what field belong to what table, especially if you have identical field names in different tables (which does happen).
>
> Hi Ilya
>
> In the case of replace I usually do the following...
>
>

REPLACE ;
> 	INCEPTION WITH DATE(), ;
> 	Category WITH "New" ;
> 	IN Customers 

>
> That's because it's very easy to type and, to me, easy to read.

No offense but can't help it, Russian proverb comes to mind: "Your laziness was born ahead of you!" :-) (The same fully applies to yours truly, BTW.)

So, what was that with "non-increasing the entropy"? :-) (Just joking.)

> The only time I add alias references is ...
>
>

SET RELATION TO SOMEFIELD INTO TABLE2
> REPLACE ;
> 	Inception with TABLE2.SomeField, ;
> 	TABLE2.Category with "New" ;
> 	IN Customers

>
> This way TABLE2 stands out very strongly as something atypical.
>
> I try to avoid adding table references to my SQL commands unless I have no choice.
>
> Mike Yearwood
> www.foxridgesoftware.com
> President: Toronto Ontario FoxPro User's Group



Regards,

Ilya