Bueno, lo que tiene en favor RDO es una mayor performance y la posibilidad de
añadir algunas capacidades (hacer que el cliente recupere el control sin esperar a que el servidor termine de procesar consulta, almacenar datos binarios como imágenes de tamaño ilimitado en la BD, ajustes de performance, etc)
Migrar a RDO una aplicación es una tarea ardua, especialmente porque aunque las diferencias no son conceptuales, sí hay diferencias en el funcionamiento que molestan. Más abajo están algunas de las diferencias y transformaciones a considerar para la migración DAO -> RDO.
Los storedprocedures tienen varias ventajas, la principal de las cuales es que
al estar ejecutándose en el servidor son más rápidas y te permiten minimizar el tráfico de red con un buen diseño.
También te envío un pequeño resúmen de cursores y bloqueos que es una traducción de la ayuda, y también están añadidos algunos temas sacado de un libro que tengo acá.

Suerte

Efren Pedroza wrote:

No es una lista exhaustiva, son sólo algunas de las cosas que encontré

1- Instalar el Service Pack 3 (en el \\Gpc_server\c\vb5\servicepack\ está como autoextraíble). Si no se instala éste, no va a andar la grida

2- Instalar como referencia RemoteDataObjects y como componente RemoteDataControl

3- Hacer los siguientes reemplazos
Todos los data control por remotedatacontrol (recordar que el tipo de resultset 3- rdopenstatic es para generar resultset de sólo lectura)
Todos los TrueDBGrid por DBGrid
Dim xx as Recordset -> Dim xx as rdoResultset
Dim xx as Database -> Dim xx as rdoConnection
datacontrol.recordset -> datacontrol.resultset
OpenRecorset -> OpenResultset
dbOpenSnapshot -> rdOpenStatic
dbOpenDynaset -> rdOpenKeyset, rdConcurLock (*)
dbOpenFordwardOnly -> rdOpenFordwardOnly
DAO.Errors -> RDO.rdoErrors
Dim xx as Error -> Dim xx as rdoError
xx.Fields() -> xx.rdoColumns ()
dbReadOnly -> rdConcurReadOnly
dbPessimistic -> rdConcurLock
dbOptimistic -> rdConcurRowVer
dbOptimisticValue -> rdConcurValues
dbOptimisticBatch -> rdConcurBatch

(*) CUIDADO: rdConcurReadOnly es el valor por defecto y no permite actualizar los registros para que funcione en forma similar a un dynaset usar:
rdConcurLock: Bloqueo pesimista.Todos los registros traídos (.RowSetSize) son bloqueados.
rdConcurRowVer:Concurrencia optimista basado en el ID de fila.
rdConcurValues:Concurrencia optimista basado en los valores de fila.
rdConcurBatch:Concurrencia optimista usando actualizaciones del modo batch.
        Son devueltos valores de estado por cada fila exitosamente actualizada.

5- Cambiar la sentencia de apertura de la conexión
Set xx = rdoEngine.rdoEnvironments(0).OpenConnection(strDSN rdDriverCompleteRequired, False, strConexión)
Con strConexión igual a strConexión = "DSN=" & strDSN & ";DATABASE=" & strNombreBaseDeDatos & ";UID=" & strUsuario & ";PWD=" & strClave

6- IMPORTANTE:
Capacidades que existen en un Recorset y desaparecen para los ResultSet
a) métodos find (FindFirst, FindNext, FindPrevious, FindLast)
b) método clone (usado para TrueDBGrid)
c) no funciona bien el ListBox común asociado con el RemoteDataControl
Sugerencia: algo que se puede hacer para listas cortas es lo siguiente Set rs = db.OpenResultSet (strSentenciaSQL,

7- Encontré problemas con TrueDBGrid

8- Diferencias entre SQL del Jet y Transact-SQL (sólo algunas...)
a- En Jet: DELETE * FROM Tabla WHERE
    En TSQL: DELETE FROM Tabla WHERE
b- En Jet: SELECT Apellido & ', ' & Nombre as Apynom FROM Tabla
    En TSQL: SELECT Apellido + ', ' + Nombre as Apynom FROM Tabla
c- En Jet: SELECT datepart ('m', campofecha) as mes FROM Tabla
    En TSQL: SELECT datepart (month, campofecha) as mes FROM Tabla
    Para las otras partes de una fecha vale el mismo tipo de transformación
d- En Jet: Existe TRANSFORM y PIVOT
    En TSQL: Brilla su ausencia

9- CUIDADO: En SQL-Server un campo tipo char que no acepta nulos se de longitud fija. Éso quiere decir que devuelve con blancos a la derecha si el contenido es más pequeño que el tamaño del campo. Se puede usar la función TSQL RTRIM para que devuelva el campo sin blancos de más.

Hay muchas más cosas para cambiar, pero éstas creo que son algunas de las más frecuentes.

Paciencia y buena suerte



Resúmen de tipos de cursor y bloqueos en SQL-Server

Tipos de cursor (CursorDriver)
Es una propiedad que se establece en en rdoEnvironment (igual función que un Workspace). Un vez que una rdoConnection fué establecida, esta propiedad es de sólo lectura.

rdUseIfNeeded(0) (por defecto)
El driver ODBC elegirá el estilo apropiado de cursor.
Los cursores del lado del servidor serán elegidos si se puede.

rdUseOdbc(1)
RemoteData usará la biblioteca de cursor ODBC.

rdUseServer(2)
Usa cursores del lado del servidor.

rdUseClientBatch(3)
RDO usará la biblioteca de cursor optimista batch.

rdUseNone(4)
El resultset no es retornado como cursor.


rdUseServer(2)
Esta biblioteca de cursor mantiene el keyset de cursor en el servidor (en TempDB) lo que elimina la necesidad de transmitir el keyset a la estación de trabajo donde consume recursos necesarios. Sin embargo, este driver de cursor consume espacio en la TempDB en el servidor remoto con lo que la base de datos debe ser expandida para cubrir estos requerimientos. Los cursores creados con un driver del lado del servidor no pueden contener más de una sentencia SELECT; si lo hacen un error atrapable ocurre. Todavía puede usar resulset con este driver con consultas de múltiples resultset si deshabilita
el cursor creando un cursor forward-only, read-only con un rowsetsize de uno. No todos los servidores remotos soportan estos cursores. Note que los cursores del lado del servidor son habilitados cuando usa rdUseIfNeeded o rdUseServer sobre Microsoft SQL Server.

rdUseOdbc(1)
Esta biblioteca de cursor construye keysets en la estación de trabajo en la RAM local desbordando en disco si es necesario. Como este diseño lleva considerablemente más operaciones de red que debe ser realizada cuando se crea el keyset, pero con cursores pequeños esto puede no imponer una carga significativa en la estación o la red. Los cursores ODBC del lado del cliente no imponen ningún tipo de restricción respecto del tipo de consulta que puede realizarse. Esta opción da mejor rendimiento con pequeños result set, pero se degrada rápidamente para resultset grandes.

rdUseClientBatch(3)
Esta biblioteca de cursor está diseñada para tratar con requerimientos especiales de actualizaciones batch optimistas y con varias capacidades complejas de cursor más. Los cursores de cliente batch son requeridos para conexiones disociadas, modo batch, y actualizaciónes multitabla. Este cursor también soporta búsquedas demoradas de columnas BLOB, memoria intermedia de cursores, y control adicional sobre las actualizaciones. Esta biblioteca es algo mayor que las otras, pero también se comporta mejor en muchas
situaciones.

rdUseNone(4)
En casos en los que necesita buscar filas rápidamente, o realizar consultas de acción sobre la base de datos sin la sobrecarga de un cursor, puede elegir intruir RDO para que evite la creación de un cursor. Básicamente, esta opción crea un resultset forward-only, read-only con un rowsetsize de uno. Esta opción puede mejorar el desempeño en muchas operaciones. Mientras no necesite actualizar filas o deslizarse entre filas con el cursor, puede mandar consultas de acción independientes para manipular los datos. Esta opción es especialmente útil cuando accede datos mediante procedimentos almacenados.


Tipos de bloqueo
Se establece al abrir el ResultSet

rdConcurReadOnly(1) (por defecto)
El cursor es de sólo lectura. No permite actualizaciones

rdConcurLock(2)
Bloqueo pesimista.Todos los registros traídos (.RowSetSize) son bloqueados.

rdConcurRowVer(3)
Concurrencia optimista basado en el ID de fila.

rdConcurValues(4)
Concurrencia optimista basado en los valores de fila.

rdConcurBatch(5)
Concurrencia optimista usando actualizaciones del modo batch.
Son devueltos valores de estado por cada fila exitosamente actualizada.


Con el bloqueo optimista las páginas son bloqueadas de modo exclusivo pero no están disponibles para otros usuarios sólo mientras se realiza la actualización. (esto es muy similar a lo que hace DAO/Jet)
* Concurrencia de solo-lectura: Esta opción no impone ningún bloqueo exclusivo en las filas tomadas. En la mayoría de los casos, sin embargo, debe garantizarse un bloqueo compartido (shared lock) para lograr acceso a las filas. En otras palabras, los otros usuarios no pueden tener bloqueos exclusivos (bloqueo de actualización o de intención) en las páginas que se accederán. Eligiendo esta opción genera un cursor de sólo lectura. Este no excluye el uso de consultas de acción para actualizar datos independientes del cursor. Este es el tipo de bloqueo por defecto.
* Concurrencia Pesimista: Esta opción pide un bloqueo exclusivo inmediato en las filas del cursor el cual implementa el mínimo nivel del bloqueo suficiente para asegurar que la fila será actualizada. A diferencia de DAO, el cual difiere el bloqueo hasta que el método edit es usado, RDO bloquea las primeras RowsetSize filas del resultset cuando el cursor es abierto con el método OpenResultSet. Esto es, si su RowsetSize es de 100 filas, el motor remoto es intruído para bloquear cada página que contiene una de las filas seleccionadas. Esto significa unas 100 páginas bloqueadas, las cuales pueden
bloquear cientos de registros. Cuando el puntero de registro actual es movido a través del resultset, páginas adicionales son bloqueadas, y aquellas que no son más referenciadas son soltadas. Esta técnica asegura a su aplicación que ninguna otra aplicación tendrá accesos garantizado (de actualización) en ninguna de las filas que son procesadas por el cursor.
* Concurrencia Optimista: Esta tipo de administración de concurrencia no bloquea ninguna fila o página, simplemente compara la fila que será enviada a la base de datos con la fila que actualmente existe en el servidor.
Dependiendo del tipo de concurrencia optimista elegida, las capas RDO y ODBC comparan o el ID de fila, o los valores de los datos, o la columna TimeStamp o combinaciones de estas opciones con los datos existentes para determinar si la fila a cambiado desde que fué leida. Si no hubieron cambios desde la última vez, la actualización es realizada. Sino, su aplicación lanza un error atrapable.

La propiedad LockType soporte tres tipos de concurrencia optimista como se describe abajo. Cuando se usa la opción rdConcurBatch, deberá también establecer la propiedad UpdateCriteria para elegir la opción apropiada de concurrencia de actualización.

* Concurrencia optimista - Versión de fila (rdConcurRowVer): Comparando el identificador de fila (usualmente la columna TimeStamp), RDO puede determinar si la fila ha cambiado desde que fué buscada. Si lo fué, resulta un error atrapable.
* Concurrencia optimista - Valores de fila (rdConcurValues): Comparando los valores de fila columna por columna, RDO puede determinar si la fila ha cambiado desde que fué buscada. Si lo fué, resulta un error atrapable.
* Batch optimista (rdConcurBatch): Este tipo de concurrencia usa la propiedad UpdateCriteria para determinar cómo probar si las filas fueron cambiadas cuando se usa el método UpdateBatch.