Soykan,

>i wantto migrate my app slowy to the SQL server.
>At this point i want to decide to using SPT (Sql Passthrough) or CA (CursorAdapter)

CursorAdapter is like a remote view (automatically-generated insert/update/delete commands) but is subclassable and is loaded with hook events that allow you to tie special processing into various steps in the process of querying and updating data (BeforeCursorFill, BeforeUpdate, AfterUpdate, etc).

This allows you to handle interesting situations programmatically that would be more difficult or impossible to do with Remote Views. For example, you could redefine the select statement on the fly by trapping the BeforeCursorFill event, taking the select statement about to be sent to the backend, and adding on some extra WHERE clause or ORDER BY clause info, then allowing the process to continue.

You could also tie in indexing of the cursor in the AfterCursorFill, add instrumentation in any of the Before events to write to a log in debugging mode, add your own IncomingConversionFunc method to fix up data right after a query (by adding a call in AfterCursorFill), and on and on.

So you get the benefits and ease of use of Remote View and avoid having to construct all of your SQL statements by string concatenation as you will likely do with SPT. CursorAdapter lends itself well to constructing a hierarchy of classes. I usually use a caBase that is subclassed from the CA class, adding in common functionality I want, then subclass that to a caUpdatable class with other added features, then subclass from that for each table I want to match a CA to.

Oh yes, CAs don't require anything to be written into a DBC and can be coded as VCX or PRG and can be added to DataEnvironments or handled completely separate from DataEnvironment.

There is a learning curve, but you do get substantial benefits once you understand the concepts.