Supongamos que tengo una tabla con una columna timestamp que se utiliza a través de NHibernate para administrar la versión de registro. Ahora estoy buscando una manera de actualizar un registro de mis datos sin aumente el valor de la columna ts, porque como sabe, ese valor aumentaría después de cada declaración de actualización para rastrear la versión de los datos y evitar problemas de concurrencia.

CREATE TABLE [dbo].[TSTest]( 
    [ID] [int] NOT NULL, 
    [Name] [nvarchar](50) NULL, 
    [ts] [timestamp] NOT NULL, 
    CONSTRAINT [PK_TSTest] PRIMARY KEY CLUSTERED ( [ID] ASC )
        WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY]

¿Alguna idea?

0
Mohammad Nikravesh 21 mar. 2017 a las 11:04

2 respuestas

La mejor respuesta

Si hay ciertas columnas que no deberían estar sujetas a seguimiento timestamp, puede mover esas columnas a una nueva tabla que luego se remite a esta tabla original.

Si lo desea, puede ocultar la existencia de esta nueva tabla y la tabla original modificada de la aplicación al producir una vista llamada TSTest que une las tablas (junto con los desencadenantes que aplican inserciones, actualizaciones y eliminaciones a las correspondientes). tablas base).

Sin embargo, en este caso no está claro qué debemos hacer, ya que solo hay una columna obvia "actualizable": Name, por lo que si no queremos que esté sujeta al seguimiento de timestamp, no está claro por qué tenerlo en esta mesa en absoluto.

Desafortunadamente, no hay otros mecanismos T-SQL para evitar el comportamiento de timestamp, y esto generalmente se ve como algo bueno. No puede hacer nada a través de disparadores, ya que si toca la tabla base, se cambiará timestamp, y no se le permite UPDATE columnas de marca de tiempo, por lo que ni siquiera puede restablecerla después cambio.

Creo que sería posible, nada es imposible en software

Dejando a un lado la existencia de cosas como el problema de detención, por supuesto tiene razón en que este problema puede resolverse, pero no de una manera que pueda serle útil. Como he dicho anteriormente, no es posible a través de T-SQL.

Si realmente necesita hacer esto, puede hacerlo manipulando directamente el archivo de la base de datos. Por supuesto, eso requiere que separe la base de datos o retire el servidor, y luego revise las estructuras de archivos para localizar manualmente las páginas que contienen las filas que desea modificar, luego aplique esos cambios y luego corrija otras partes de la estructura (como sumas de verificación de página) para que SQL Server no crea que las páginas ahora están corruptas.

Realmente no estoy abogando por este enfoque, solo describo cuán lejos de la normalidad tendrías que ir para realizar lo que estás pidiendo.

1
Damien_The_Unbeliever 21 mar. 2017 a las 08:34

¿Alguna idea?

Según su comentario y esquema, su columna ts [ts] [timestamp] NOT NULL. Por lo tanto, se modificaría en cada operación de actualización.

Una forma podría ser usar un activador AFTER UPDATE y deshacer la modificación. ¿Pero por qué harías eso? Además, el disparador en la misma tabla (o) disparador recursivo no es compatible con MySQL.

1
Rahul 21 mar. 2017 a las 08:17