CursorAdapters don't work well in n-tier because they create a cursor. If the tiers are physically separated, you can't pass the cursors without converting them to something else (XML?).

Also, if you currently are using RVs and the TABLEUPDATE() and other commands sit in the UI, then you DON'T have a good n-tier design.


>Hi All,
>
>I'm busy in maintaining a huge VFP app where local and remote views are used. This application can use both a VFP and SQL server backend.
>
>The Maintenance on the remote views is of a concern as it does require a lot of time to create and maintain them.
>
>We are looking into two different options to get away from the remote views and create a n-tier architecture.
>1. CursorAdapters
>2. The tightline data classes
>
>To me personally the cursoradapters look very attractive to me. The transition from remote views to cursoradapters is not that much. The VFP commands like REQUERY(), REFRESH(), TABLEUPDATE(), aERROR() and tracking update conflicts are just about 100% compatible. We want to create those cursoradapters on the fly with the help of metadata stored in a table that will specify the SQL commands that will populate the cursor.
>
>The tightline data classes have been arround for a while and are supposed to be rock solid tested etc. However from looking at it, it does not seem as powerfull as cursoradapters.
>
>My question is:
>1. Who has used cursor adapters for a mission critial application? Whats your experience?
>2. Who has encountered showstoppers to use any of the two approaches. What are those?
>3. Any additional advice is welcome.
>
>Walter,