José Alfonso,
> Estamos obcecados con la idea de mantener conexiones permanentes con el
> servidor,
Y harás bien, es de lo que más tiempo, CPU y tráfico consume.
>le decimos que con las clases prácticamente no tienen que saber SQL y ahí
>está nuestro error.
Te aseguro que no es así, al menos en el caso de Xailer. Una cosa es la
sentencia de SQL y otra cosa es el manejo del cursor generado por la
sentencia. Creo que no se deben confundir. Es cierto que Xailer pemite hacer
operaciones de altas, bajas y edición directamente sobre DataSets (cursores)
pero son operaciones SQL tremendamente básicas que exigen sin embargo
grandes cantidades de codificación si se hacen a mano. No tiene ningún
sentido hacerlo a mano.
> - Conectar
> - Realizar operacion
> - Desconectar
Una perdida de tiempo innecesaria en mi opinión. Cada día son más
complicados los sistemas de autentificación lo cual implica mayor tráfico de
red y mayor uso de CPU y los servidores SQL cada vez que tienen o pierden
una conexión deben de realizar reasignaciones de memoria. Tanto es así, que
muchas soluciones Middleware ofrecen una cache de conexiones, es decir, se
mantienen 100 conexiones abiertas que se comparten entre todas las
peticiones Web, por ejemplo.
Un saludo,
"Jose Alfonso Suárez Moreno" <
jasm.nospam@chochurro.com> escribió en el
mensaje news:43552bf6$[email=
1@ozsrvnegro.ozlan.local...]
1@ozsrvnegro.ozlan.local...[/email]
> Jose,
>
> No tengo nada contra ADO ni contra los datasources, pero siempre me ha
> gustado coger por el camino más directo para hacer las cosas. SQL es SQL,
> no tiene nada que ver con DBF, ni mucho menos. Son dos cosas totalmente
> distintas.
>
> Está bien que se busque la facilidad para hacer las cosas, pero hacer las
> cosas fáciles no implica intentar copiar el modelo actual (DBF). Hay que
> saber aceptar los cambios y sobre todo si el cambio conlleva gran parte de
> identidad propia.
>
> Estamos obcecados con la idea de mantener conexiones permanentes con el
> servidor, obtener refrescos de la consulta realizada de forma instantánea,
> obligar a la gente a trabajar en el error de que SQL puede ser usado como
> DBF, sin preocuparnos de la potencia que ofrecen los servidores SQL (y la
> limitación de que se trabaja con datos virtuales en el cliente).
>
> A diario me llegan mensajes de usuarios acostumbrados a las DBF que usan
> las tablas SQL de la misma forma (sea con Eagle 1, o con cualquier otro
> sistema de clases), quejandose de que SQL es lento para presentar una
> lista de albaranes con el nombre del cliente al lado.... Cuando reviso el
> código me doy cuenta de que no saben SQL, eso es culpa de ellos, pero es
> culpa nuestra el presentarles las tablas SQL como si de tablas DBF se
> tratase para que terminen haciendo un "SELECT *" a la tabla de clientes
> por linea del browse para obtener sólo el nombre.
>
> Otra de las cosas que me suelen preguntar es como manejar índices.... En
> SQL no son necesarios los índices (excepto el de la clave primaria) ya que
> se obtienen las consultas ordenadas desde el servidor. El tema es que hay
> gente que se pone a crear índices al estilo DBF (cantidades exageradas),
> lo que hace, además, que los procesos de actualización sean lentos. Bien,
> es culpa del usuario que no sabe SQL, pero volvemos a lo mismo, le decimos
> que con las clases prácticamente no tienen que saber SQL y ahí está
> nuestro error.
>
> Por otro lado y para terminar, mi forma de trabajar con SQL se basa en que
> los datos están en un servidor remoto y que no se debe mantener una
> conexión permanente:
>
> - Conectar
> - Realizar operacion
> - Desconectar
>
> Esa es mi forma de trabajo. Y hasta ahora me va mejor que bien. Sólo hay
> que tener en cuenta el hacer el refresco de la consulta actual, bien sea
> de forma automática, bien sea de forma manual.
>
> Y no me enrrollo más. Si en Madrid tengo un hueco ya contare más cosas a
> los que se interesen.
>
> Saludos,
>
> Jose A. Suarez
>
>
> Jose F. Gimenez escribió:
>> Paco,
>>
>> sinceramente... espera un poco. Dentro de poco haremos un datasource para
>> ADO. Mi consejo es que si estás acostumbrado a las dbf y no has usando
>> SQL anteriormente, lo mejor es hacerlo con ADO, que es lo más parecido a
>> las dbf que puedes encontrar en SQL.
>>
