Hola, Diego.
>Hacer una aplicacion en red (no web) capaz de funcionar con dbc SQL Y dbc VFP:
>uno u Otro, (no con los dos a la vez). Y que sea facil de trabajar !!!
Hay varias alternativas. Puedes armar un framework propio o utilizar uno que ya tenga esto implementado. Si quieres probar uno gratuito que te permite hacer esto (incluso trabajar con diferentes fuentes de datos a la vez en forma transparente y sin tener que recompilar la aplicación, sólo cambiando archivos de configuración), mira:
http://sourceforge.net/projects/tieradapter/>Pero no que se vuelva lenta a causa de la carga o actualizacion de los datos.
Esto no depende tanto del mecanismo de acceso a datos sino de la manera en que diseñes tu base de datos, cómo utilices los índices, y también cómo realicen las consultas. Si haces un buen trabajo en estos aspectos, no importa que mecanismo de acceso utilices, el rendimiento de la aplicación no debería variar -para el mismo volúmen de resultados- cuando aumenta el volúmen de datos.
>ODBC:
> Segun Microsoft se ha dejado atras por ser lento. Y suplantado por
>ADO ya que ADO trabaja como interfaz de OLE DB y este trabaja en el plano
>de bajo nivel de datos binarios y su acceso es mas rapido.
>¿¿¿ ESTO ES ASI REALMENTE ???
No se dónde leíste que Microsoft dijera que era lento. ODBC tiene otros problemas, pero la lentitud no es el principal. OleDB es una tecnología totalmente diferente que permite muchas más cosas,
>ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
>o por medio del ODBC.
No es así. ADO es el cliente estándar de OleDB. No utiliza ODBC, salvo indirectamente, si utilizas el OleDB provider para ODBC.
> ODBC: Segun lo anterior no usare hacer la coneccion por medio del ODBC.
>
> OLE DB: Segun lo que estuve viendo es una forma rapida de conectar con los
> datos y funciona sin problemas, aunque no es tan adaptable como el cursor
> adapter ya que en ADO los commandos no son los nativos de fox.
> Pero si funciona muy bien.
No compares OleDB con CursorAdapter. Son cosas totalmente diferentes. De hecho, CursorAdpater puede utilizar ODBC, ADO y otros tipos de conexión. Estás comparando capas diferentes.
>CURSOR ADAPTER:
> Funciona muy bien con ADO, la coneccion la haces con el
>controlado OLE DB y manejas el cursor adapater con los comandos
>nativos del FOX. Aqui la cuestion es que al estar usando ADO que es
>realmente una interfaz de OLE DB ya estamos usando una via.
>(la otra opcion es usar C). Luego tenemos que pasar el cursor de ADO
>(que se llama recordset) al cursor adapter para cargar a este. Y luego
>de trabajr con el cursoradapter desde los comandos del fox, para
>registrar los cambios tenemos que pasarlos los datos de vuelta al
>cursor de ADO (recordset) y hacer que los cambios se hayan hechos
>efectivos y verificar que eso sea asi.
>¿¿¿ AQUI NO SE QUE TANTO ES ESTO !!! Asi funciona, pero realmente
>se pondra lento el sistema o es una mia de milisegundos ????
La conversión es inmediata. Te aseguro que el equipo de VFP logró un mecanismo sumamente eficiente. No hubiesen incorporado este mecanismo de no ser así. Hay formas de resolver el acceso a datos a más bajo nivel que en determinados contextos pueden ser más eficientes, pero requieren mucho conocimiento para poder implementarse.
>Esto es asi realmente ? Solo tendria que cambar el tipo de coneccion
>(en ADO.CONNECTION) y con solo una linea de cambio de codigo estaria
>resuelto ? Me encanta las soluciones faciles ya trabajar con el
>cursoradapter se haria facil el codigo.
TierAdpater se basa en CursorAdapter y XmlAdapter, y te simplifica el modelo de programación aún más. Suena a publicidad, pero como el framework es gratuito... 8-)
>3 CAPAS:
> Si uso la coneccion de ADO no hay problema ya que esta
>hecho para esta situacion (3 capas).
>
> En el caso de cursor adapter, vi una idea en un foro de hacer
>la capa de datos con la coneccion de ADO y la parte del cursor adapter
>ponerla en de la interfaz y usar la modalidad de DESCONECTADO.
>¿¿¿ AQUI NO SE SI CONECTARME Y DESCONECTAR DOS VECES CADA TRANSACCION
>HARIA QUE EL SISTEMA SE PUSIERA AUN MAS LENTO ???
Otra vez mezclas cosas, amigo. Hasta ahora hablabamos de mecanismos de acceso a datos, y ahora ya involucras el resto de las capas...
Bien, mantener las capas desconectadas es la forma de hacer que la aplicación se más escalable. Si la infraestructura es la correcta, la conexión y desconexión no debería afectarte mucho, porque en realidad la haces contra un pool de conexiones (por ejemplo en COM+).
>DOS APLICACIONES:
>1) Hacer la aplicacion en VFP nativas, pero usando
>en las consultas sentencias SQL sean lo más ANSI posible.
>Asi a la hora de cambiar del a SQL, se podra hacer con
>pocos cambios.
Esto es una ilusión. He visto a esta altura docenas de intentos de este tipo en la comunidad Fox y todos fracasan inevitablemente. La única manera de hacer una aplicación portable es que la desarrolles y pruebes contra las distintas plataformas TODO el tiempo.
>2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
>¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???
Te diría que te preocupes menos por la velocidad y más por entender conceptualmente las tecnologías. El rendimiento de tu aplicación no dependerá tanto de estos mecanismos sino de cómo los utilices, y sobre todo de la manera en que diseñes e implementes la base de datos y el código.
Saludos,
