Existe la necesidad de que un cliente registre cada cambio de datos en una tabla de registro con el usuario real que realizó la modificación. La aplicación utiliza un usuario de SQL para acceder a la base de datos, pero debemos registrar la identificación de usuario "real".Registrando cada cambio de datos con Entity Framework
Podemos hacerlo en t-sql escribiendo disparadores para cada inserción y actualización de tabla, y usando context_info para almacenar la identificación de usuario. Pasamos el ID de usuario a un procedimiento almacenado, almacenamos el ID de usuario en el contexto, y el desencadenador podría usar esta información para escribir filas de registro en la tabla de registro.
No encuentro el lugar o la forma en la que puedo hacer algo similar con EF. Entonces, el objetivo principal es: si realizo un cambio en los datos a través de EF, me gustaría registrar el cambio de datos exacto en una tabla de forma semiautomática (por lo tanto, no deseo verificar si hay cambios en todos los campos). guardando el objeto). Estamos usando EntitySQL.
Desafortunadamente tenemos que seguir con SQL 2000, por lo que la captura de cambios de datos introducida en SQL2008 no es una opción (pero quizás tampoco sea la correcta para nosotros).
¿Alguna idea, enlace o punto de partida?
[Editar] Algunas notas: mediante el uso de ObjectContext.SavingChanges eventhandler, puedo conseguir el punto donde pueda inyectar la instrucción SQL para inicializar el contextinfo. Sin embargo, no puedo mezclar el EF y el SQL estándar. De modo que puedo obtener EntityConnection pero no puedo ejecutar una instrucción T-SQL usándolo. O puedo obtener la cadena de conexión de EntityConnection y crear una SqlConnection basada en ella, pero será una conexión diferente, por lo que el contexto no afectará el guardado realizado por el EF.
He intentado lo siguiente en el controlador SavingChanges:
testEntities te = (testEntities)sender;
DbConnection dc = te.Connection;
DbCommand dcc = dc.CreateCommand();
dcc.CommandType = CommandType.StoredProcedure;
DbParameter dp = new EntityParameter();
dp.ParameterName = "userid";
dp.Value = textBox1.Text;
dcc.CommandText = "userinit";
dcc.Parameters.Add(dp);
dcc.ExecuteNonQuery();
de error: El valor de EntityCommand.CommandText no es válida para un comando StoredProcedure. Lo mismo con SqlParameter en lugar de EntityParameter: SqlParameter no se puede utilizar.
StringBuilder cStr = new StringBuilder("declare @tx char(50); set @tx='");
cStr.Append(textBox1.Text);
cStr.Append("'; declare @m binary(128); set @m = cast(@tx as binary(128)); set context_info @m;");
testEntities te = (testEntities)sender;
DbConnection dc = te.Connection;
DbCommand dcc = dc.CreateCommand();
dcc.CommandType = CommandType.Text;
dcc.CommandText = cStr.ToString();
dcc.ExecuteNonQuery();
Error: La sintaxis de la consulta no es válida.
Así que aquí estoy, atascado para crear un puente entre Entity Framework y ADO.NET. Si puedo hacerlo funcionar, publicaré una prueba de concepto.
serio el usuario quiere que uses EF y luego requiere que se pega con SQL 2000? –
Hay una publicación interesante relacionada con la auditoría [aquí] (http://blogs.msdn.com/b/simonince/archive/2009/04/20/auditing-data-changes-in-the-entity-framework-part- 2.aspx), ¿qué piensas? – ibiza
Seis años después y sigo pensando que este es un gran enfoque. Los desencadenadores son mucho mejores para la auditoría que el código de nivel de aplicación, y esto proporciona una forma ingeniosa de obtener información de usuario 'real' en la capa de db sin contaminar el código de la aplicación. – Rory