> >
> > 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).
> >
> > HTH.
> >
> > Regards,
> >
> > Ilya
>
> But in the case of queries, please use query aliases.
>
>

SELECT C.col1, C.col2, O.col2, O.col3 
>  FROM Customers AS c JOIN Orders AS O ON C.key=O.key 

> It can make big multi-table queries oh so much easier to read. The View and Query Designers support this when use the Add Table dialog.
>
> Another standard for many SQL publishers is to put SQL keywords in upper case, table names i proper case and column names in lower case. Inceases readability.
>
> Yet another naming standard. Table names are plural, column names singualar. I dislike the VFP convention of prefixing a datatype letter to column names, but I like the advise in the HGelp topic 'Object Naming Conventions" and "Naming Conventions" (except for table column naming).
>
> -Anders
>
> -Anders

Personally I find Customers.Col1 easier to read then C.Col1

Regards
Tushar