>I am having too much fun with 32bit ODBC Excel 97 Driver and maybe someone >can halp me to understand that I am doing wrong. >I have a spreadsheet in Excel 97 format with range name excMyRange and in >VFP 5.0 I have a database container with connection based on ODBC Excel 97 >and updateble View called MyView. I can query the data in view but if I try >to change it I get ODBC error (or I think it is ODBC error) saying "This >operation requires Updatable query". I think my query is updateble then why >ODBC thinks it is not ? >Please share any expirience with ODBC VFP and Excel spreadsheets. I would >like to be able to update data in spreadsheets using VFp and ODBC. > >Thank you. I'm playing around with filling up an Excel 97 workbook with values entered via VFP forms (I simply hate entering data in Excel - no incremental search, date format is not configurable the way I like it...). I've discovered some things by now: - most of the columns appear to be of Memo type, and should best be left that way. The ODBC driver is leaning heavily on the sheet column format, but once there's some data of other type in some cell in a column, it reverts from defaulting to Double numbers to Memo again. A slightest change in sheet structure makes the view unusable, and the only way to get it up and going is to Modi View again, reselect all the fields, accept the default data types and hope for the best. Yes, there must be a primary key column - I've defined it as 8-digit integer in Excel, and it works. I've been trying to reconstruct the view programmatically, taking what GenDbc generated, but as soon as I've left the constant strings it made and replaced them with vars (there are six workbooks with the same structure, so I wanted to replicate behavior and achieve consistency), the views I got that way were complaining a lot and either wouldn't update, or would report some cryptical ODBC errors or just required DbSetProp("Tables", ---). Well, DbGetProp said it was ok, the table was the proper one, though it was surrounded with quotes; I've removed the quotes but no good either. The next obstacle was that there was a lot of interpunction in Excel sheet (blanks, for one) which got translated into underscores for view field names. The killer combination had only R/N which did get into R_n, but remained unqouted in the SQL statement (visible) and the update statement (invisible - and it's quite a phantom). So finally I've ended up with just three sheets (I'll derive other five from the third one, for which I've clicked my way through), and the remaining problem is Unicode. There's no decent way to persuade Excel to accept the data entered in the view as CP 1250 (though Fox marks it internally as 1250), so they end up as CP 1252 in Excel's Unicode. If everything else fails, I might just write a macro in Excel, and call it via DDE or OLE after transfer, but I feel like a bad failure if I can't do it from Fox. Anyone tried that?