sobre RS desconectados

En asp no tienes otra opción que trabajar con recordset desconectados... no
entiendo tu duda tu abres una conexión, creas un recordset y haces algo
con él, normalmente lo "pasas" a una tabla html y cierras el recordset y la
conexión todo antes de que se ejecute nada en el cliente si dejas la
conexión y el recordset abiertos, lo único que logras es sobrecargar el
servidor pues desde el cliente son inacesibles.

Sashka

"Hernán Castelo" escribió en el mensaje
news:#

los RS desconectados...
entiendo que le alivia recursos al servidor
pero son seguros?
no son suceptibles de ser manipulados?
quién gestiona los Updates?
queda en el servidor
alguna especie de puntero al RS desconectado
(alojado en el cliente) ??


gracias de antemano
por los comentarios

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .

.

. . . .

gracias por responder :

Si el recordSet está en la PC del cliente
no puede una persona
abrir ese recordSet de ninguna manera???
a eso me refiero cuando pregunto si es seguro

Por eso mismo pregunto
el servidor mantiene de alguna manera
una lista de dónde están sus recordSets desconectados
es decir cómo valida que al reconectar
el recordSet sea el mismo enviado la primera vez
(no me refiere a los cambios o inserciones
sino al recordSet mismo)

Luego
quién gestiona las actualizaciones ?
o sea quién gestiona la autenticidad de la
conexión/ re-conexión
el IIS?

Y cómo se manejan las actualizaciones
por clave (primary key)?
y si el recordSet estaba filtrado
por una condición especial?
por ej, eran todos los datos
de una sola persona,
por lo tanto no figura el ID de la persona??
cómo se actualizan esos datos ??

gracias nuevamente
espero que ahora se comprenda



atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

"Sashka" escribió en el mensaje
news:

En asp no tienes otra opción que trabajar con recordset desconectados...

no

entiendo tu duda tu abres una conexión, creas un recordset y haces

algo

con él, normalmente lo "pasas" a una tabla html y cierras el recordset y

la

conexión todo antes de que se ejecute nada en el cliente si dejas

la

conexión y el recordset abiertos, lo único que logras es sobrecargar el
servidor pues desde el cliente son inacesibles.

Sashka

"Hernán Castelo" escribió en el mensaje
news:#
> los RS desconectados...
> entiendo que le alivia recursos al servidor
> pero son seguros?
> no son suceptibles de ser manipulados?
> quién gestiona los Updates?
> queda en el servidor
> alguna especie de puntero al RS desconectado
> (alojado en el cliente) ??
>
>
> gracias de antemano
> por los comentarios
>
> atte,
> Hernán Castelo
> UTN - Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . .

.

.
> . . . .
>
>

El recordset no llega nunca al cliente al cliente llega el html con los
datos que tu hayas escrito en él leyendo el recordset. es como cuando
ves el código fuente de una página asp sólo verás el html generado... no
hay forma de "reconectarse"... si tu presentas los datos de un registro en
un formulario y luego miras en el código fuente, verás que no hay ninguna
referencia al recordset... y su el usuario cambia algun dato, por ejemplo,
al submitir el formulario recibes el dato con un request.form("campo") ,
deberás crear tu sentencia sql, abrir una conexión y ejecutarla la
conexión con la que hayas abierto el recordset original ya no estará
disponible... aun cuando no la hayas cerrado antes Con respecto a como
se manejan las actualizaciones... no importa como hayas filtrado el
recordset original. tu sentencia sql de actualización deberá incluir la
clave para que ADO erncuentre el registro que quieres actualizar.

Si tenemos un recordset así: "Select campo1,campo2, campo3 from ejemplo"

Y después quieres actualizar determinado registro tu sql será algo asi:
"update ejemplo set campo2 = 'aaaaa' where campo1='algo'"

Sashka

"Hernán Castelo" escribió en el mensaje
news:

gracias por responder :

Si el recordSet está en la PC del cliente
no puede una persona
abrir ese recordSet de ninguna manera???
a eso me refiero cuando pregunto si es seguro

Por eso mismo pregunto
el servidor mantiene de alguna manera
una lista de dónde están sus recordSets desconectados
es decir cómo valida que al reconectar
el recordSet sea el mismo enviado la primera vez
(no me refiere a los cambios o inserciones
sino al recordSet mismo)

Luego
quién gestiona las actualizaciones ?
o sea quién gestiona la autenticidad de la
conexión/ re-conexión
el IIS?

Y cómo se manejan las actualizaciones
por clave (primary key)?
y si el recordSet estaba filtrado
por una condición especial?
por ej, eran todos los datos
de una sola persona,
por lo tanto no figura el ID de la persona??
cómo se actualizan esos datos ??

gracias nuevamente
espero que ahora se comprenda



atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .

.

. . . .

"Sashka" escribió en el mensaje
news:
> En asp no tienes otra opción que trabajar con recordset desconectados...
no
> entiendo tu duda tu abres una conexión, creas un recordset y haces
algo
> con él, normalmente lo "pasas" a una tabla html y cierras el recordset y
la
> conexión todo antes de que se ejecute nada en el cliente si

dejas

la
> conexión y el recordset abiertos, lo único que logras es sobrecargar el
> servidor pues desde el cliente son inacesibles.
>
> Sashka
>
> "Hernán Castelo" escribió en el mensaje
> news:#
> > los RS desconectados...
> > entiendo que le alivia recursos al servidor
> > pero son seguros?
> > no son suceptibles de ser manipulados?
> > quién gestiona los Updates?
> > queda en el servidor
> > alguna especie de puntero al RS desconectado
> > (alojado en el cliente) ??
> >
> >
> > gracias de antemano
> > por los comentarios
> >
> > atte,
> > Hernán Castelo
> > UTN - Buenos Aires
> > . . . . . . . . . . . . . . . . . . . . . . . .
.
> .
> > . . . .
> >
> >
>
>

gracias Sashka
ah, muy bien
yo pensaba que el RS quedaba de alguna forma
escrito en el disco del cliente... qué suerte que no

pero estoy algo confundido

yo hasta ahora lo único sé hacer es
crear el RS y mandarlo al cliente con Response.Write
luego, cuando el usuario submita el form
ya no puedo consultar ese cursor
porque yo escribí Html

veo que se utilizan RS enlazados a datos
o bien RS de "ADOR" o "ADOC"...
vos hablás de alguno de esos casos (enlazados)?

me pasarías algún ejemplo o link

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .

"Sashka" escribió en el mensaje
news:

El recordset no llega nunca al cliente al cliente llega el html con

los

datos que tu hayas escrito en él leyendo el recordset. es como cuando
ves el código fuente de una página asp sólo verás el html generado...

no

hay forma de "reconectarse"... si tu presentas los datos de un registro en
un formulario y luego miras en el código fuente, verás que no hay ninguna
referencia al recordset... y su el usuario cambia algun dato, por ejemplo,
al submitir el formulario recibes el dato con un request.form("campo") ,
deberás crear tu sentencia sql, abrir una conexión y ejecutarla la
conexión con la que hayas abierto el recordset original ya no estará
disponible... aun cuando no la hayas cerrado antes Con respecto a como
se manejan las actualizaciones... no importa como hayas filtrado el
recordset original. tu sentencia sql de actualización deberá incluir

la

clave para que ADO erncuentre el registro que quieres actualizar.

Si tenemos un recordset así: "Select campo1,campo2, campo3 from ejemplo"

Y después quieres actualizar determinado registro tu sql será algo

asi:

"update ejemplo set campo2 = 'aaaaa' where campo1='algo'"

Sashka

"Hernán Castelo" escribió en el mensaje
news:
> gracias por responder :
>
> Si el recordSet está en la PC del cliente
> no puede una persona
> abrir ese recordSet de ninguna manera???
> a eso me refiero cuando pregunto si es seguro
>
> Por eso mismo pregunto
> el servidor mantiene de alguna manera
> una lista de dónde están sus recordSets desconectados
> es decir cómo valida que al reconectar
> el recordSet sea el mismo enviado la primera vez
> (no me refiere a los cambios o inserciones
> sino al recordSet mismo)
>
> Luego
> quién gestiona las actualizaciones ?
> o sea quién gestiona la autenticidad de la
> conexión/ re-conexión
> el IIS?
>
> Y cómo se manejan las actualizaciones
> por clave (primary key)?
> y si el recordSet estaba filtrado
> por una condición especial?
> por ej, eran todos los datos
> de una sola persona,
> por lo tanto no figura el ID de la persona??
> cómo se actualizan esos datos ??
>
> gracias nuevamente
> espero que ahora se comprenda
>
>
>
> atte,
> Hernán Castelo
> UTN - Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . .

.

.
> . . . .
>
> "Sashka" escribió en el mensaje
> news:
> > En asp no tienes otra opción que trabajar con recordset

desconectados...

> no
> > entiendo tu duda tu abres una conexión, creas un recordset y haces
> algo
> > con él, normalmente lo "pasas" a una tabla html y cierras el recordset

y

> la
> > conexión todo antes de que se ejecute nada en el cliente si
dejas
> la
> > conexión y el recordset abiertos, lo único que logras es sobrecargar

el

> > servidor pues desde el cliente son inacesibles.
> >
> > Sashka
> >
> > "Hernán Castelo" escribió en el

mensaje

> > news:#
> > > los RS desconectados...
> > > entiendo que le alivia recursos al servidor
> > > pero son seguros?
> > > no son suceptibles de ser manipulados?
> > > quién gestiona los Updates?
> > > queda en el servidor
> > > alguna especie de puntero al RS desconectado
> > > (alojado en el cliente) ??
> > >
> > >
> > > gracias de antemano
> > > por los comentarios
> > >
> > > atte,
> > > Hernán Castelo
> > > UTN - Buenos Aires
> > > . . . . . . . . . . . . . . . . . . . . . . .

.

> .
> > .
> > > . . . .
> > >
> > >
> >
> >
>
>

Efectivamente... eso es lo que te vengo diciendo.. ya no puedes consultar
ese cursor con respecto a usar rs enlazados... yo nunca lo he visto
a no ser que exista algún ocx pero como te digo cuando la pagina está
cargada. está del lado del cliente y al submitirla es como si se cargara
por primera vez... eso lo manejas preguntando por los request que serán
cadena vacía la primera vez... y tendrán valor las siguientes

Sashka

"Hernán Castelo" escribió en el mensaje
news:e$

gracias Sashka
ah, muy bien
yo pensaba que el RS quedaba de alguna forma
escrito en el disco del cliente... qué suerte que no

pero estoy algo confundido

yo hasta ahora lo único sé hacer es
crear el RS y mandarlo al cliente con Response.Write
luego, cuando el usuario submita el form
ya no puedo consultar ese cursor
porque yo escribí Html

veo que se utilizan RS enlazados a datos
o bien RS de "ADOR" o "ADOC"...
vos hablás de alguno de esos casos (enlazados)?

me pasarías algún ejemplo o link

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .

.

. . . .

atte,
Hernán Castelo
UTN - Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .

.

. . . .

"Sashka" escribió en el mensaje
news:
> El recordset no llega nunca al cliente al cliente llega el html con
los
> datos que tu hayas escrito en él leyendo el recordset. es como

cuando

> ves el código fuente de una página asp sólo verás el html

generado...

no
> hay forma de "reconectarse"... si tu presentas los datos de un registro

en

> un formulario y luego miras en el código fuente, verás que no hay

ninguna

> referencia al recordset... y su el usuario cambia algun dato, por

ejemplo,

> al submitir el formulario recibes el dato con un request.form("campo") ,
> deberás crear tu sentencia sql, abrir una conexión y ejecutarla la
> conexión con la que hayas abierto el recordset original ya no estará
> disponible... aun cuando no la hayas cerrado antes Con respecto a

como

> se manejan las actualizaciones... no importa como hayas filtrado el
> recordset original. tu sentencia sql de actualización deberá incluir
la
> clave para que ADO erncuentre el registro que quieres actualizar.
>
> Si tenemos un recordset así: "Select campo1,campo2, campo3 from ejemplo"
>
> Y después quieres actualizar determinado registro tu sql será algo
asi:
> "update ejemplo set campo2 = 'aaaaa' where campo1='algo'"
>
> Sashka
>
> "Hernán Castelo" escribió en el mensaje
> news:
> > gracias por responder :
> >
> > Si el recordSet está en la PC del cliente
> > no puede una persona
> > abrir ese recordSet de ninguna manera???
> > a eso me refiero cuando pregunto si es seguro
> >
> > Por eso mismo pregunto
> > el servidor mantiene de alguna manera
> > una lista de dónde están sus recordSets desconectados
> > es decir cómo valida que al reconectar
> > el recordSet sea el mismo enviado la primera vez
> > (no me refiere a los cambios o inserciones
> > sino al recordSet mismo)
> >
> > Luego
> > quién gestiona las actualizaciones ?
> > o sea quién gestiona la autenticidad de la
> > conexión/ re-conexión
> > el IIS?
> >
> > Y cómo se manejan las actualizaciones
> > por clave (primary key)?
> > y si el recordSet estaba filtrado
> > por una condición especial?
> > por ej, eran todos los datos
> > de una sola persona,
> > por lo tanto no figura el ID de la persona??
> > cómo se actualizan esos datos ??
> >
> > gracias nuevamente
> > espero que ahora se comprenda
> >
> >
> >
> > atte,
> > Hernán Castelo
> > UTN - Buenos Aires
> > . . . . . . . . . . . . . . . . . . . . . . . .
.
> .
> > . . . .
> >
> > "Sashka" escribió en el mensaje
> > news:
> > > En asp no tienes otra opción que trabajar con recordset
desconectados...
> > no
> > > entiendo tu duda tu abres una conexión, creas un recordset y

haces

> > algo
> > > con él, normalmente lo "pasas" a una tabla html y cierras el

recordset

y
> > la
> > > conexión todo antes de que se ejecute nada en el cliente si
> dejas
> > la
> > > conexión y el recordset abiertos, lo único que logras es sobrecargar
el
> > > servidor pues desde el cliente son inacesibles.
> > >
> > > Sashka
> > >
> > > "Hernán Castelo" escribió en el
mensaje
> > > news:#
> > > > los RS desconectados...
> > > > entiendo que le alivia recursos al servidor
> > > > pero son seguros?
> > > > no son suceptibles de ser manipulados?
> > > > quién gestiona los Updates?
> > > > queda en el servidor
> > > > alguna especie de puntero al RS desconectado
> > > > (alojado en el cliente) ??
> > > >
> > > >
> > > > gracias de antemano
> > > > por los comentarios
> > > >
> > > > atte,
> > > > Hernán Castelo
> > > > UTN - Buenos Aires
> > > > . . . . . . . . . . . . . . . . . . . . . .

.

.
> > .
> > > .
> > > > . . . .
> > > >
> > > >
> > >
> > >
> >
> >
>
>