First of all for compatibility reasons. All VFP tables with long field names in eality have short field names in the tables themselves, the long field names are stored in the DBC. This means that in many cases you must be very careful. For instance if you remove a DBF from a DBC, all the long field names are 'gone'.

Please note that I am only talking about native DBF files, in SQL server it's another story. Although you will still face the problems with SELECT xxx INTO yyy READWRITE and subsequent ALTER TABLE commands, which I use a lot.

Someone asked why someone would SELECT into a cursor which does not have the correct strucure, one of the reasons is speed. Here is a real code snippet from one of my applications:

SELECT master.ID, slave.ord FROM sokeord as master, sokeord as slave WHERE slave.ord = lcSok AND master.id = slave.id;
  INTO CURSOR curPris READWRITE
IF GETWORDCOUNT(lcInn) > 1
  FOR lnTeller = 2 TO GETWORDCOUNT(lcInn)
    lcSok = GETWORDNUM(lcInn, lnTeller)
    SELECT master.ID, slave.ord FROM curPris as master, sokeord as slave WHERE slave.ord = lcSok AND master.id = slave.id;
      INTO CURSOR curPris READWRITE
  ENDFOR
ENDIF
SELECT DIST ID FROM curPris INTO CURSOR curPris READWRITE 
SELECT prislist.* from prislist,curPris WHERE prislist.ID=curPris.id INTO CURSOR curPris READWRITE

My two DBFs both have about two million records, but still the response is almost instant. Also note the loop where the from cursor and into cursor have the same name, I don't think it is commonly known that you can do that when you use the READWRITE clause.



>Why do you recommend to NOT use long field names? The problem in this thread is not a good enough reason for me.
>
>>Since I never use long field names, and never have had the need for it the last 15 years, that is not any problem in my programs. I strongly recommend NOT to use long field names, I don't see any benefit at all. But needs may vary, of course.
>>