>Try "Save As"
Easier: since I already have a list of date column names, I'm simply widening the column so the .text will be a digit now:
PROCEDURE GetColumnNames(tn)
LOCAL aF[1], lnfields
loXls=this.oexcel
loxls.ActiveSheet.ROWS(tn).SELECT
loxls.SELECTION.COPY()
_CLIPTEXT=TRIM(_CLIPTEXT, 1, 0h0d)
lnfields=ALINES(aF, _CLIPTEXT, hTab)
DIMENSION THIS.aFld[lnFields]
ACOPY(aF, THIS.aFld)
FOR i=1 to lnFields
IF lower(af[i])$this.cValueFieldsList
loxls.columns(i).ColumnWidth = 15.57
endif
ENDFOR
Which now works even without saving the file. I just wish I didn't have to waste so much time on this.
>>I'm importing a few hundred megabytes of data from various excel sheets, just like I always did, nothing new.
>>
>>Or so I thought.
>>
>>It's the dates. The sheets are the 97/2003 format, which open fine in my excel 2003. However, the client has excel 2010 installed, and that's where the trouble began. The date fields' cell.value would return an OLE error if there was the long negative value which represents a null date, instead of returning a null like it did in 2003.
>>
>>So I had to check the cell.text... which would be "####" of some length in such cases.
>>
>>Except it's not. It's hashes whenever Excel 2010 can't display the date in full length - and if it's a 97/2003 file, it doesn't even try to widen the column. So I had to open each file, widen the date columns, save... and then it wouldn't save in xls format, it insists on xlsx (maybe there's an option to allow saving in xls, but it's hidden somewhere, and it would already be about tenth option on top of those I had to search for before it would even open these files).
>>
>>It wasn't broken, but thanks my good luck, they fixed it. Or at least tried to.