cual es la mejor coneccion ? (ADO, SQL PASS TROU) desde fox

PROPOSITO:
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 !!!
Pero no que se vuelva lenta a causa de la carga o actualizacion de los
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 ???
-

ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
o por medio del 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.



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 ????

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.


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 ???


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.


2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???


ate, deigo santos

PROPOSITO:
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 !!!
Pero no que se vuelva lenta a causa de la carga o actualizacion de los
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 ???
-

ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
o por medio del 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.



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 ????

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.


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 ???


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.


2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???


ate, deigo santos

Primero, No puedes establecer una conexion por OLE DB; el cual es la
especificacion sobre la cual funciona ADO, asi que el objeto a usar es ADO y
si, funciona muy bien.

Cito MSDN:

"Universal Data Access Overview"
OLE DB is the Microsoft system-level programming interface to diverse
sources of data. OLE DB specifies a set of Microsoft Component Object Model
(COM) interfaces that encapsulate various database management system
services. These interfaces enable you to create software components that
comprise the Universal Data Access platform.

Whereas OLE DB is a system-level programming interface, ADO is an
application-level programming interface. ADO, based on Automation, is a
database-programming model that allows enterprise programmers to write
applications over OLE DB data from any language including Visual Basic,
Java, VBScript, JScript, and C/C++.


suerte,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"diego santos" escribió en el
mensaje news:
> PROPOSITO:
> 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 !!!
> Pero no que se vuelva lenta a causa de la carga o actualizacion de los
> 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 ???
> -
>
> ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
> o por medio del 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.
>
>
>
> 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 ????
>
> 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.
>
>
> 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 ???
>
>
> 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.
>
>
> 2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
> ¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???
>
>
> ate, deigo santos
>

PROPOSITO:
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 !!!
Pero no que se vuelva lenta a causa de la carga o actualizacion de los 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 ???

-

ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
o por medio del 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.

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 ????

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.

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 ???

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.

2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???

Hola Diego, mira entre lineas mi opinión al respecto

diego santos wrote:
> PROPOSITO:
> 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 !!!
> Pero no que se vuelva lenta a causa de la carga o actualizacion de los 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 ???


Bueno yo uso VFP7 y VFP9 con conexiones ODBC hacia SqlSErver 2005 sin
ningún problema, ni lentitud.

también uso ODBC con MySql.

> -
>
> ADO: La coneccion se puede hacer por medio de el provedor de OLE DB,
> o por medio del 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.
>
>


Si usas ADO, tenes que convertir los recordsets a cursores de Fox, lo
que podría hacerse lento si tus datos son muchos.


>
> 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 ????
>
> 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.
>

Eso dice la teoría :), si usas CA con ADO, seria los mismo que usarlo
sin CA, lo unica diferencia es que el CA hara la conversión del
recordset a cursor nativo de VFP, y no creo que sea mas rapido.

Yo nunca he trabajado con Ado desde Fox, mas que para hacer pruebas,
pero debido a las conversiones que tenes que hacer, creo que si seria
mas lento en *comparación* a si lo hicieras directamente con ODBC.

>
> 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 ???
>

Si, es es una buena opción, en donde la capa intermedia sea la que se
encargue de todo lo concerniente a conexiones, actualizaciones, etc.

Si queres ver un ejemplo de como hacerlo mira aqui:

http://mbsoftwaresolutions.com/down.../ntier.exe
http://leafe.com/forum/viewtopic.php?t11

Es para MySql y DBfs, pero te da la idea de como hacerlo con MSSQlSErver


>
> 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.
>

Dos aplicaciones, definitivamente no, es mejor la idea de 3 capas.


>
> 2) Hacer la aplicacion con la tecnica de PASS TROUGH a SQL.
> ¿¿¿ ESTA TIPO de TECNICA ES LO MAS RAPIDO ???
>
>

Con STP estarias siempre usando ODBC, y si es rapido, debido a que no
tenes que hacer ninguna conversión posterior al obtener los datos desde
el servidor.


Otra opción que tenes es hacerlo usando Views, con esto solo tendrías
que cambiar la DBC para vistas locales o vistas remotas, según tu
necesidad, pero cambien estarías usando ODBC.



HTH


Saludos
Jaime Vasquez
Guatemala C.A.