Conectado o Desconectado ?

Estoy de acuerdo contigo que una titulación no implica necesariamente
ser mejor profesional (en este caso informático) ni viceversa. A lo que me
refería es que me cuesta pensar que si una empresa como Microsoft apuesta
por el modelo desconectado es porque alguna ventaja tendrá, no?

Creo que, como mínimo, mantener las conexiones abiertas consume recursos
en el servidor y por supuesto el estar siempre conectado produce bloqueos.
Son dos ventajas a tener en cuenta.

¿Podrías explicar a lo que te refieres con "reinventar" todos los
servicios de integridad y cálculo que ofrece un SGBD?


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

y por supuesto el estar siempre conectado produce bloqueos.

Si hablas de por ejemplo una aplicacion windows con sql server, eso no es
cierto. No produce ningun bloqueo una simple conexion abierta. Los bloqueos
pueden ser por operaciones de manipulacion de data, actualizaciones,
cursores, etc.

Ademas, una pregunta, cuando hablan de "desconectado" se refieren a que uno
copie toda la data desde el servidor a la terminal ?

Si es eso, no seria muy lento estar copiando cada vez esos datos para
manipularlos localmente?

Pedro, una conexión, por el simple hecho de estar abierta (estamos
hablando de SQL Server), sí produce bloqueos. No son bloqueos exclusivos
(que son lo de los que se producen con las actualizaciones que comentas)
pero sí compartidos y como todo bloqueo, son recursos del servidor.

Si no me crees, haz la prueba tú mismo: entra en tu equipo de desarrollo
(local) y abre una conexión. Ejectua SP_LOCK y verás cómo existe un bloqueo
de tipo "DB" (base de datos) que está en modo "S" y estado "GRANT"
(concedido), eso sin haber ejecutado ninguna sentencia (simplemente por
estar conectado).


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Echavarria" escribió en el mensaje
news:

>y por supuesto el estar siempre conectado produce bloqueos.
>

Si hablas de por ejemplo una aplicacion windows con sql server, eso no es
cierto. No produce ningun bloqueo una simple conexion abierta. Los

bloqueos

pueden ser por operaciones de manipulacion de data, actualizaciones,
cursores, etc.

Ademas, una pregunta, cuando hablan de "desconectado" se refieren a que

uno

copie toda la data desde el servidor a la terminal ?

Si es eso, no seria muy lento estar copiando cada vez esos datos para
manipularlos localmente?

Ok. Yo pensaba que te referias a bloqueos exclusivos de esos que impiden
actualizaciones a los demas usuarios.



"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:

Pedro, una conexión, por el simple hecho de estar abierta (estamos
hablando de SQL Server), sí produce bloqueos. No son bloqueos exclusivos
(que son lo de los que se producen con las actualizaciones que comentas)
pero sí compartidos y como todo bloqueo, son recursos del servidor.

Si no me crees, haz la prueba tú mismo: entra en tu equipo de
desarrollo
(local) y abre una conexión. Ejectua SP_LOCK y verás cómo existe un
bloqueo
de tipo "DB" (base de datos) que está en modo "S" y estado "GRANT"
(concedido), eso sin haber ejecutado ninguna sentencia (simplemente por
estar conectado).


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Pedro Echavarria" escribió en el mensaje
news:

>y por supuesto el estar siempre conectado produce bloqueos.
>

Si hablas de por ejemplo una aplicacion windows con sql server, eso no es
cierto. No produce ningun bloqueo una simple conexion abierta. Los

bloqueos

pueden ser por operaciones de manipulacion de data, actualizaciones,
cursores, etc.

Ademas, una pregunta, cuando hablan de "desconectado" se refieren a que

uno

copie toda la data desde el servidor a la terminal ?

Si es eso, no seria muy lento estar copiando cada vez esos datos para
manipularlos localmente?

On Tue, 1 Aug 2006 11:03:36 -0400, "Pedro Echavarria"
wrote:

Ademas, una pregunta, cuando hablan de "desconectado" se refieren a que uno
copie toda la data desde el servidor a la terminal ?

Si es eso, no seria muy lento estar copiando cada vez esos datos para
manipularlos localmente?

Eso es lo de menos, el problema es que localmente no tenemos SQL para
manipular ni asegurar la integridad de los datos y hay que hacerlo con
medios muy primitivos.


Saludos