Ciao Andrea, ciao a tutti

SQL SERVER 2017 stesso risultato.

 
SQLVersion
---------------------------------------------------------------------------
Microsoft SQL Server 2017 (RTM-GDR) (KB4505224) - 14.0.2027.2 (X64) 
  Jun 15 2019 00:26:19 
  Copyright (C) 2017 Microsoft Corporation
  Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 18362: )


COLUMN_NAME DATA_TYPE
Id          int
ts          timestamp

COLUMN_NAME                                                                                                                      
Id          int
rv          timestamp

colName                                                                                                                          
Id          int
ts          timestamp

colName                                                                                                                          
Id          int
rv          timestamp


Completion time: 2019-10-08T22:59:38.0550308+02:00
.

Ma... a questo punto... tutte le "vecchie" tabelle con timestamp devo modificarle con uno script che sostituisce timestamp con rowversion ?

Ho alcuni database con il TD timestamp in produzione... se NON faccio questa modifica e lascio il "vecchio" timestamp cosa rischio ?

Saluti e grazie
salve Filippo,
al momento non rischi niente, ma visto che il data type e' deprecato, in un qualche futuro aggiornamento, probabilmente NON potrai aggiornare il livello del db da (ad esempio) SQL Server 2017 (compatibility level 140) a SQL Server 202x (compatibility level 2xx), a meno che non deprechino completamente l'utilizzo, ed in quel caso il db NON sara' agganciabile all'istanza.... ad esempio una cosa simile e' successa con la sintassi JOIN 89, deprecata, che ora il parser rileva come errore e non esegue il codice sollevando subito l'eccezione...


Ma... a questo punto... tutte le "vecchie" tabelle con timestamp devo modificarle con uno script che sostituisce timestamp con rowversion ?


qui sai benissimo che il problema lo risolvi facile... la colonna NON contiene mai un'informazione rilevante ai fini gestionali... per certi versi ti basta uno script che effettui il drop della colonna in ogni tabella e ne ricrei una con stesso nome ma con tipo di dato rowversion... occhio ai vincoli di schema binding che potresti avere :D
personalmente gia' lo feci a partire da SQL 2008... non ho db in giro con "timestamp" :D

in effetti NON so bene cosa cambi a livello di catalogo, visto che abbiamo rilevato che sia INFORMATION_SCHEMA che le catalog management views restituiscono comunque "timestamp"... l'informazione di tipo di dato effettivo a noi non pare disponibile ma spero vivamente che nel db sia presente

staremo a vedere
saluti omnia

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
Ciao Andrea...

Se può interessare nel visual studio 2019 SCHEMA COMPARE del database le tabelle con TIMESTAMP vengono viste come ROWVERSION.

 
CREATE TABLE [syo].[tUserType] (
    [IDUserType]  SMALLINT      NOT NULL,
    [ID_dt]       DATETIME      CONSTRAINT [DF_t_user_type_ID_dt] DEFAULT (getdate()) NOT NULL,
    [RowVer]      ROWVERSION    NOT NULL, *** IN REALTA' QUESTA E' UNA TIMESTAMP ***


ma io non ho cambiato nulla...

Inoltre se butto la colonna TIMESTAMP e creo la stessa ma ROWVERSION nel visual studio 2019 SCHEMA COMPARE la modifica sulla tabella NON viene nemmeno rilevata dallo SCHEMA COMPARE.

Ovvero da per buono che in ogni caso quel TIMESTAMP è un ROWVERSION (ma non è vero non ho cambiato nulla) anche se nessuno ha sostituito il tipodato.

Oppure... ipotizzo che quando ho passato la compatibilità del database a sql server 2017 sql server ha cambiato "d'autorità" il tipo dato sulle tabelle

Se fosse cosi non è per niente simpatica la cosa...

dormo preoccupato ? :)

Filippo
:D

al momento non saprei cosa rispondere, perche' non avendo accesso al valore presente nel db, ogni risposta e' buona e cattiva allo stesso tempo... non ti dico "stai sereno" perche' politicamente ci sono stati problemi con questa affermazione, in passato :D, ma ti direi di "dormire tranquillo" lo stesso :D:D
poi vedremo alla prossima edizione... in ogni caso, d'ora in poi, utilizza sicuramente "rowversion" e non "timestamp" nei ddl... :D

salutoni omnia

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.