>I'm having a problem with an application that has been running in VFP3 for >over a year. MSSQL 6.5 with Foxpro as front-end. I am using parameterized >views in the data environment of the forms and this works well for the >majority of the app. I like to use SQLEXEC to return a cursor for specific >data searches and for reporting. These are not updateable - they are meant >to be read-only. > >Since moving this app to VFP5, when using this SQLEXEC code to return a >cursor with 'text' (Memo) fields, I am getting an error 'No update tables >specified. Use the Tables property of the cursor.' Using >=cursorgetprop('tables') I determine that the underlying table is not, in >fact, specified. But even specifying it with >=cursorsetprop('tables','tablename') does not clear the error. I am unable >to access the cursor or the memo field without getting the error. I have >tested the code pulling different fields that are not 'text/memo' fields >and have no problem accessing the cursor or the fields in it. When I >request a cursor with the text/memo fields, I cannot access the cursor >fields by name in code, copy the cursor to a local table, or anything. > >If I create a view in the .dbc for this instead of using SQL passthrough, >it works also. I don't want to create extra views in my dbc that I have >not needed up to now. > >I spoke with Microsoft about this today and the representative indicated >there may be something broken with ODBC but will be getting back to me. >Has anyone else had this happen? > >TIA >Gail I've had it much the same, when I was trying to fill some Excel sheets from within VFP5.0 - as long as I used wizard-generated remote views, it worked kind of fine but defined most of the columns (numerics too) as memos (!). Then I redefined some of them to be numeric and some to be c(40), then it worked sometimes and sometimes not. Then I found out it won't work if the sheet was empty, so I ran Excel and filled in some data. Then VFP insisted on rebuilding the view, since the original table structure was changed, and got me memo fields all over again. Another PITA was the slash which appeared in one column title, which was regularly replaced with an underscore in the view's, but didn't get the field name surrounded with quotes in the SQL statement (as it did when the title contained spaces)... played all day with it. In parallel, I decided that having to play around and click endlessly just to get the view structure right was pointless, so I ran GenDbc and pulled out the definition of the view. When I ran the view which was defined programmatically, I got exactly 'No update tables specified. Use the Tables property of the cursor.', but CursorGetProp returned the proper table name, quotes included (!). Then I set it to no quotes, but to no avail - it never really worked. I wanted to have the programmatically set view working, because there were some five Excel sheets with identical structure (four of them are filters on the fifth, but who ever heard of views within Excel :), so I wanted to have a routine to run a common definition for both of them, and finally I gave up. Now I update only one view, and the filtered sheets contain full references to the master sheet, having just a filter in one column set differently. I got a 600K Excel file for some 80K of ..dbf ;(, but what the hell. I had promissed to deliver the data in Excel format, and didn't promise anyone will like it, including me.