problemas con la cache de Linqtosql

muchas gracias a todas por las respuestas. Muy interesantes.

"Octavio Hernandez" escribió en el mensaje
de noticias news:%23mzckz$

Jesús,

Una respuesta muy concisa y completa!
Efectivamente, el método del contexto que mencionas es Attach(). Un buen
post sobre el método es éste:


http://blogs.msdn.com/dinesh.kulkar...ached.aspx

Slds - Octavio



"Jesús López" wrote in message
news:uiZ7Z8%

Para no tener que leer dos veces puedes tienes dos opciones:

1) Mantener el mismo contexto en la lectura y al guardar los cambios. Es
decir:
1.1 Creas un contexto Ctx.
1.2 Mediante el contexto Ctx obtienes los datos
1.3 Muestras los datos
1.4 El usuario hace cambios sobre los objetos
1.5 Guardas los cambios usando el mismo contexto creado en 1.1

2) Anexar los objectos al contexto antes de hacer los cambios:
2.1 Creas un contexto Ctx1
2.1 Medianto Ctx1 obtienes los datos
2.2 Destruyes el contexto Ctx1
2.3 Muestras los datos
2.4 El usuario hace cambios sobre los objetos
2.5 Creas un nuevo contexto Ctx2
2.5 Anexas los objectos que han cambiado a Ctx2. (Método Attach o algo
así, no recuerdo exactamente)
2.6 Guardas los cambios usando Ctx2
2.7 Destruyes el contexto Ctx2

Saludos:

Jesús López
www.solidq.com




"[Juanjo]" escribió en el mensaje
news:%

Gracias, ya sabia que podia ejecutar una instruccion sql.

La idea que yo tenia era aprovechar un poco mas el Ling,

Cuando recoges un registro de una tabla personas, por ejemplo:

var reg = (from persona where loquesea select lomismo);
persona p=reg.First();
p["nombre"]="otro Nombre";

// Siendo ctx. el DataContext
ctx.SubmitChanges(); //creo que era esta funcion

Ya actualiza el registro en cuestion.

El problema como comento es que si haces una funcion para recuperar la
persona, solo el select, y haces otra
para el Update, tienes que ejecutar una consulta para recuperar el
registro que quieres actualizar.

No se si me he explicado bien.


"Julian" escribió en el mensaje de noticias
news:

// Siendo ctx. el DataContext
// el parametro query será la consulta que actualice "UPDATE .
WHERE
// parameters = los parametros que tu deses para la consulta.
ctx..ExecuteQuery<T>(string query, params object[] parameters)

"[Juanjo]" escribió en el mensaje
news:

Gracias octavio:

El problema no es solo con un registro en concreto, creo que es mas
porque usaba un objeto DataContext para toda la aplicacion,todas las
consultas, sorprendentemente,
si para cada funcion creo un objeto, si que me coge los cambios.

Hay una cosa que no me gusta mucho del LinqtoSQL y no se si por mi
desconocimiento, te cuento. Quiero actualizar un registro de la base
de datos vale?
Mi forma de trabajar es aislar el acceso a la base de datos, por lo
que bueno, mas o menos:
1. Recojo los datos (Select).
2. Muestro los datos.
3. Actualizo los datos.

Antes de usar Linq, para actualizar directamente llamaba a una funcion
que ejecutaba el "update", pero con Linq, tengo que hacer una consulta
previa para traer el registro que quiero actualizar, porque no puedes
hacer como antes "update. where clave=loquesea", y lo que no me
gusta es eso precisamente, el tener que hacer un select antes del
update.

Hay alguna otra forma de hacerlo?

Muchas gracias.

Hola Jesús,

El Wed, 1 Oct 2008 20:05:03 +0200, Jesús López escribió:

LINQ no está tan mal hecho como dices. No es perfecto, desde luego.

Eso lo lo dirás tú, pero yo le he oido decir literalmente a expertos en
bases de datos de primera fila internacional que es como para salir
corriendo.

Da la impresión de que sólo como lo haces tú está bien hecho.

En algunos casos así es, y por eso lo digo :-)

Creo que
deberías mostrar más respeto al trabajo de los demás.

Yo no entiendo por que tendría que mostrar respeto por un trabajo mal
hecho. Si un trabajo está mal hecho pues habrá que decirlo, sino como vas a
esperar que lo arreglen.

Si un cantante canta mal le abuchean, si un árbitro se equivoca le pitan,
si un sistema operativo es malo la gente no se actualiza, si una
herramienta de programación es mala los programadores le muestran su
respeto. Así nos va.

Soy yo el que debería de quejarme de que los demás no os quejais y pasais
de todo :-)

No haces más que
ponerle faltas a todo, pero poco enseñas a hacer las cosas bien (o como
piensas que deben hacerse).

Ya, ahora resulta que yo no digo como creo que deben de hacerse las cosas.
Creo que es la primera vez que me dicen eso :-)

A Linq tenían que haberle añadido instrucciones equivalentes a insert
delete y update de SQL, que menos que eso. Lo del SubmitChanges() es como
para degradarlos a todos a becarios.


Saludos
Alfredo

El Wed, 1 Oct 2008 19:56:55 +0200, Jesús López escribió:

Para no tener que leer dos veces puedes tienes dos opciones:

1) Mantener el mismo contexto en la lectura y al guardar los cambios. Es
decir:
1.1 Creas un contexto Ctx.
1.2 Mediante el contexto Ctx obtienes los datos
1.3 Muestras los datos
1.4 El usuario hace cambios sobre los objetos
1.5 Guardas los cambios usando el mismo contexto creado en 1.1

2) Anexar los objectos al contexto antes de hacer los cambios:
2.1 Creas un contexto Ctx1
2.1 Medianto Ctx1 obtienes los datos
2.2 Destruyes el contexto Ctx1
2.3 Muestras los datos
2.4 El usuario hace cambios sobre los objetos
2.5 Creas un nuevo contexto Ctx2
2.5 Anexas los objectos que han cambiado a Ctx2. (Método Attach o algo
así, no recuerdo exactamente)
2.6 Guardas los cambios usando Ctx2
2.7 Destruyes el contexto Ctx2

Un gran progreso comparado con el antiguo: no hacía falta hacer nada.

Y eso que este es uno de los casos más sencillos que se pueda uno imaginar.


Saludos

El Wed, 1 Oct 2008 20:21:49 +0200, Jesús López escribió:

Por cierto, yo también tengo críticas para LINQ to SQL en cuanto a las
actualizaciones.
...
Esto va totalmente en contra de la filosofía de las bases de datos
relacionales en las que la idea es "macroscópica", osea orientada de
conjuntos de filas en vez de "microscópica", o sea haciendo un procesamiento
fila a fila.

Por lo menos estamos de acuerdo en algo. Esto es un fallo garrafal.

Sin embargo es posible hacer esto último en LINQ to SQL, ya que LINQ to
SQLpermite ejecutar directamente sentencias SQL.

Pues vaya cosa si al final voy a tener que estar incrustando código SQL
cada dos por tres. ¿No eras tú el que hablaba hace poco de la
"homogenieidad". Si voy a tener que escribir unas consultas en Linq y otras
en SQL pues para eso ya las hago todas en SQL y me ahorro los muchos otros
problemas que tiene Linq.


Saludos
Alfredo

Pues vaya cosa si al final voy a tener que estar incrustando código SQL
cada dos por tres. ¿No eras tú el que hablaba hace poco de la
"homogenieidad". Si voy a tener que escribir unas consultas en Linq y
otras
en SQL pues para eso ya las hago todas en SQL y me ahorro los muchos otros
problemas que tiene Linq.

Cierto que es una falta de homogeneidad, pero al menos es posible. Y por
otra parte te ahorras un montón de instrucciones de modificación registro a
registro que siempre son necesarias en las aplicaciones.

No es que me guste LINQ to SQL, pero reconozco que con él es posible crear
con éxito aplicaciones

Saludos:

Jesús López