Dmitry,

we are not concerned with the new datatypes in SQL server, so ODBC is good enough for us. I've never used ADO and I personally don't see a reason why I should use it. I've seen that people are having problems with ADO as well.

BTW, scanning the cursors, even when a couple of thousand records, in practise does not impact much on performance.

Walter,





>
>Thank you very much for a detailed message. All that you do makes sense. The only thing I am wondering if it is necessary is to convert Dates from 1910/1/1 to empty in VFP UI. Doesn't it take the entire scan of the cursor? This could take some time especially when you are retrieving data for a report with, say, a couple of thousand rows. But I suppose there is a price for everything.
>
>Right now my bigger issue (as you might have seen from other threads I started) is what DataSourceType to use with my CA class. Many suggested to use ADO but I ran into an issue where the VARCHAR(MAX) is not converted to Memo. The ODBC, however, does not know how to deal with new Date type in SQL 2008. I am still testing various options.
>
>>Dmitry,
>>
>>We use the same strategy. The cursoradapters are dynamically created out of meta data which is stored in a DBF files, which on its turn is embedded into the executable.
>>
>>FWIW, our new framework creates a cursoradapter dynamically through a simple function call.
>>

oDataHandler.Makeview(cSql, cAlias, cCursorSchema, cUpDateInfo, lNodata)

>>
>>cSql = Written in SQL server SQL but will be translated (best effort) to the appropriate backend (e.g VFP) if possible. Functions like CASE WHEN .. END are translated automatically to ICASE, (0) and (1) will be translater to .F. and .T. etc.
>>
>>cCursorSchema = optional, can specify exceptions only, so only the columns which need to be force a data type, precision and default value. A * will specify that the remaining columns will be set automatically. This way you can create views that don't need maintenance when adding columns
>>
>>cUpdateinfo = See cursoradapter documententation. If the source and dest fields are the same, only the sourcefields need to be specified. You can use the asterisk * to specify which fields needs to be updated. If you are using a three character prefix which is unique to the table, you can use arguments like "Mytable,tbl_pk, Tbl_*" to specify that only fields beginning with tbl_ will be updated.
>>
>>Our cursoradapters also have additional bonusses as it writes changed to an audit trail. Can validate the data against validation rules. (If it violates a rule, the TABLEUPDATE() will fail and the error can be obtained through AERROR()). When retrieving dates or date times from the backend, it will automaticall blank the dates when the date stored in SQL server < '1910/1/1}. In combination with the audit trail, it is possible to travel back in time, meaning that the view shows the contents as it would have been shown on a certain date and time. The framework itselfs holds a reference to the CA object and you can close the CA by simply closing the alias.
>>
>>We use a only one define CA class by default, but for exceptional cases you can use a specific one. This we do in one instance where a lot of datamunging needs to be done. The nice thing is that this all happens in the CA object and thus is entirely encapsulated. Your calling code does not have a clue what is going on internally and therefore keeps your calling code clean and simple.
>>
>>All in all, its very transparent and from a programming point of view, you use very much the same commands as with normal remote and local views. REQUERY(), TABLEUPDATE(), TABLEREVERT(),GETNEXTMODIFIED() are all perfectly integrated.
>>
>>We have a huge application that is build opun local and remote views, and we want to get away from them as there is a large number of views which get unmaintanable over time. It takes up megabytes in an embedded DBC and its really a pain to change the views again and again and create new ones for each new piece of functionality. Our new definition table stores the same views but is only about 20% of the size of the internal DBC. The bonus is that we can create views on the fly and don't need to store them explicitely in a definition table. So only ones that are used many times will end up there. The ones that are only used once will be created in code.
>>
>>
>>Walter,
>>
>>
>>
>>>
>>>I want to implement a data-driven approach of defining properties of various CursorAdapter objects in my application. So I need to store the values of the column names, types, etc. etc. in meta table(s). I am considering 3 options for meta data:
>>>
>>>1. .DBF files (even though the application work with SQL Server database)
>>>2. XML files
>>>3. Table(s) in SQL Server.
>>>
>>>Which one of the above you (collectively) would use? TIA.