problemas con la cache de Linqtosql

24/09/2008 - 13:22 por [Juanjo] | Informe spam
hola gente:

Tengo el siguiente problema, estoy seguro de que es una tonteria, pero
no doy.

tengo una aplicacion que accede a una base de datos SQL server con LINQ.

Cuando realizo esto:
1. Ejecuto 2 veces la misma aplicacion.
2. Accedo al mismo registro de la misma base de datos desde las dos
ejecuciones
3. Desde una ejecucion modifico algun dato
4. Desde la otra ejecucion vuelvo a recuperar el mismo registro
5. Esta ultima ejecucion no "ve" los cambios efectuados.

Alguien sabe como limpiar la cache?

Muchas gracias

Preguntas similare

Leer las respuestas

#16 Alfredo Novoa
02/10/2008 - 18:14 | Informe spam
El Thu, 2 Oct 2008 14:56:15 +0200, Jesús López escribió:

Mostrar la cita
No te ahorra nada que no te hubieses ahorrado ya antes una clase del tipo
de DataAdapter.

Mostrar la cita
Ya, y también con un teclado que solo tiene un cero y un uno :-)


Saludos
Alfredo
#17 Jesús López
02/10/2008 - 18:45 | Informe spam
Mostrar la cita
Que yo sepa los data adapters no generan insert update ni delete.

Mostrar la cita
Sin comentarios.



Saludos:

Jesús López
#18 Alfredo Novoa
02/10/2008 - 19:56 | Informe spam
El Thu, 2 Oct 2008 18:45:57 +0200, Jesús López escribió:

Mostrar la cita
No, pero te los puede generar un commandbuilder asociado al dataadapter,
que más dará ese detalle.

Lo que quería mostrar es que Linq además de obligarnos a hacer chapuzas
para poder actualizar conjuntos, no aporta ninguna mejora para la
actualización de registros de uno en uno, además de los nuevos problemas
como el de Juanjo.

Por lo que he visto al final hay bastante poca gente que se atreva a usarlo
para cosas serias.

Mostrar la cita
Es que menuda chorrada, hasta con la peor herramienta se pueden desarrollar
proyectos con éxito, pero quien sería tan tonto como para usar una mala
herramienta pudiendo usar una buena.


Saludos
#19 Jesús López
03/10/2008 - 10:17 | Informe spam
"Alfredo Novoa" escribió en el mensaje
news:c46exav0e75n.19b1ko8pw0sh7$
Mostrar la cita
Es más eficiente y sencillo actualizar con LINQ to SQL que con dataadapter +
commandbuilder..


Mostrar la cita
Si, exáctamente la misma "chapuza" que de la otra manera: "enviar consultas
sql"

Mostrar la cita
LINQ to SQL permite un mejor control de la concurrencia optimista. Y un
tratamiento más sencillo de las transacciones que con dataadatper +
commandbuilder.


Mostrar la cita
Lo de Juanjo no es un problema, sólo que no tenía claro algunas cosas.

Por ejemplo tienes un formulario donde cargas y actualizas los datos. Sólo
voy a poner el esqueleto de la parte de carga y actualización:

public class MiForm : Form
{
private MiDataContext dataContext;

public MiForm()
{
InitializeComponents();
dataContext = new MiDataContext();
}

private void Cargar()
{
MiDataGrid.DataSource = (from dataContext.EntidadX where lo que sea
select EntidadX).ToList();
}

private void Guardar()
{
dataContext.SummitChanges();
}

}

Simplemente tienes que mantener una referencia al data context, para leer y
guardar los datos con la misma instancia.

Mostrar la cita
Lo que sí es una verdadera chorrada es decir que con un teclado con sólo un
cero y un uno puedes desarrollar proyectos con éxito.


Mostrar la cita
Alguien quien no sepa cual es la buena y cual es la mala.

Discutamos qué tiene de bueno y de malo LINQ to SQL dando detalles concretos
y comparándolos con otras cosas. Así podremos determinar si realmente es tan
malo como dices, cosa que pongo en duda.

Por ejemplo:

En lo malo: LINQ to SQL sólo funciona con SQL Server. Algunas cosas se han
hecho para hacerlo funcionar con otros motores, pero dudo que hayan tenido
mucho éxito.

En lo bueno: Evita en gran medida la inyección de código SQL.




Saludos:

Jesús López
#20 Alfredo Novoa
03/10/2008 - 12:01 | Informe spam
El Fri, 3 Oct 2008 10:17:30 +0200, Jesús López escribió:

Mostrar la cita
Yo hablaba de clases del estilo del dataadapter, y no especificamente del
dataadapter, por que el dataadapter y ADO.NET en general es otro desastre
como casi todo lo que hace Microsoft últimamente relacionado con las bases
de datos.

También es mucho más sencillo actualizar con mi bindinglist que con LINQ to
SQL, y también es más sencillo con Delphi y con FoxPro y con montones de
otras herramientas de hace 10 años o más.

Mostrar la cita
Enviar consultas SQL a través de un "framework" diseñado para no tener que
incrustar consultas SQL en el código. Y además necesitamos crear clases
para cada tabla sin necesidad. Hasta tú has reconocido que andar mezclando
consultas Linq con consultas SQL supone una falta de homogeneidad en el
código, es decir, una chapuza.

Mostrar la cita
Esto es una chorrada. La concurrencia la controla el SGBD. Lo que aporta
Linq es más complejidad innecesaria.

Por ejemplo en el caso descrito aquí:

http://msdn.microsoft.com/en-us/lib...99373.aspx

Linq lanza una excepción y hace que la actualización falle cuando en
realidad no hay ningún conflicto. Con mi BindingList este ejemplo
funcionaría perfectamente sin lanzar ningún error.

Aquí hay otro ejemplo de conflicto inexistente que además "resuelven" de
una forma absurda.

http://msdn.microsoft.com/en-us/lib...99354.aspx

El resultado lógico es: Alfred, Mary, Marketing, sin ninguna excepción ni
otras gaitas.

Mostrar la cita
Lo único que te ahorras es no tener que asignarles una transacción a los
SqlCommand. Una mínima automatización que cualquiera se podría montar en 5
minutos en caso de que le interesase. Un detalle de muy poca importancia
comparado con todo lo demás.

Mostrar la cita
¿Y con esto se te actualizan automáticamente los datos cuando se cambian
desde otra aplicación?

Si es así entonces eso está bien.

Mostrar la cita
Si se es un "real programmer" y un machote claro que se puede :-) El
teclado de Chuck Norris solo tiene un 0 y un 1 :-)

Era una ironía, por eso llevaba la sonrisa, pero aquí no te pillan las
cosas ni aun explicándolas como en Barrio Sésamo.

Mostrar la cita
La sintaxis es horrible, no permite consultar todo lo que permite SQL, no
tiene instrucciones de actualización , pretende evitar el código SQL
incrustado pero no lo consigue, obliga a definir clases inútiles, es
innecesariamente complejo, no permite trabajar con las expresiones LinQ
como si fuesen expresiones normales, solamente deja cargar en listas, no
permite definir reglas de integridad ni tablas ni vistas en la aplicación,
etc, etc. Cuanto más lo miras en detalle más fallos se ven.

Mostrar la cita
Cosa que también evitaba todo lo que había antes desde hace muchos años.


Saludos
Ads by Google
Search Busqueda sugerida