none
MODIFY_DATE eines Objektes ändert bei Restore bzw. Attach RRS feed

  • Frage

  • Hallo Zusammen,

    kann man verhindern das sich das MODIFY_DATE (SYS.OBJECTS)
    der DB-Objekte ändert, wenn ich eine DB von einer ältern SQL - Version
    per Attach bzw. Restore auf einen neueren SQL-Server einspiele
    (z.B. 2000 -> 2005; 2005 -> 2008) bzw. kann man das MODIFY_DATE
    nachträglich ändern?

    Hintergrund ist Folgender: Ich möchte Änderungen an Proceduren
    und Views erkennen und vergleiche dafür das CREATE_DATE
    mit dem MODIFY_DATE eines Objekts. Da im oben geschilderten
    Fall aber das MODIFY_DATE nie dem urspr. CREATE_DATE entspricht,
    funktioniert auch meine Logik nicht mehr.

    Hat jemand hierfür ne Idee?

    Gruß
    Micha
    Donnerstag, 2. Dezember 2010 09:51

Alle Antworten

  • Hallo Micha,

    das kannst Du nicht verhindern.
    Die Datumsspalten sind für eine "Änderungsnachverfolgung" von SQL Server Objekten nicht geeignet.
    Sie reflektieren nur Werte, die für den SQL Server wichtig sind. Und bei einer Aktualisieren
    der (internen) SQL Server Version ist das für ihn eine Änderung.

    Um Änderungen an Prozeduren und Sichten nachzuverfolgen, verwende den vollständigen Sicht-/Prozedurtext.
    Und gewöhnlich täte man das mit einem Versionskontrollsystem, das kann Microsoft TFS oder Subversion usw. sein.

    Damit erreicht man dann mehr als einen 1:1 Vergleich, da man die Änderungen nachverfolgen kann.

    (Es gibt auch Produkte wie z. B.: http://www.red-gate.com/products/SQL_Source_Control/
    ohne damit jetzt eine Empfehlung aussprechen zu wollen - ich kenne das Produkt nicht näher)

    Gruß Elmar

    Donnerstag, 2. Dezember 2010 10:32
  • Hallo Elmar,

    vielen Dank für Deine Antwort, das habe ich mir schon fast gedacht.

    Ein Versionskontrollsystem ist aber leider nicht für meine Zwecke geeignet, da
    ich diesen Vergleich beim DB-Update unserer Software benötige, um zusehen,
    ob der Kunde Proceduren bzw. Views seinen Bedürfnissen angepaßt hat und
    wir diese deshalb nicht mit updaten dürfen. Bis zum SQL 2000 war das kein Problem,
    da habe ich die Spalte SCHEMA_VER überprüft. Sobald sie größer 0 war, wurde
    die Procedure oder View geändert. Ab der dem 2005er ist diese Spalte aber
    immer 0 und scheinbar nur noch für die Abwärtskompatibilität da.

    Da bleibt mir wohl nur noch der Text-Vergleich :-(

     

    Gruß Micha

    Donnerstag, 2. Dezember 2010 15:27
  • Hallo Micha,

    kannst Du vieleicht mit der Abfrage was anfangen:

    declare @curr_tracefilename varchar(500)
    declare @base_tracefilename varchar(500)
    declare @indx int
    
    select @curr_tracefilename = path from sys.traces where is_default = 1
    set @curr_tracefilename = reverse(@curr_tracefilename)
    select @indx = PATINDEX('%\%', @curr_tracefilename)
    set @curr_tracefilename = reverse(@curr_tracefilename)
    set @base_tracefilename = LEFT( @curr_tracefilename,len(@curr_tracefilename) - @indx) + '\log.trc';
    
    select 
    	td.ObjectID,
    	o.type OjectType,
    	'['+td.DatabaseName+'].['+s.name+'].['+td.ObjectName+']' FullObjectName,
    	(case td.EventClass when 46 then 'create' when 47 then 'drop' when 164 then 'alter' end) EventClass,
    	td.StartTime,
    	td.LoginName,
    	td.NTUserName,
    	td.ApplicationName
    from
    	::fn_trace_gettable(@base_tracefilename,default) td	inner join sys.objects o
    	on td.ObjectID = o.[object_id] inner join sys.schemas s
    	on o.[schema_id] = s.[schema_id]
    where
    	EventClass in (46,47,164)
    	and EventSubclass = 0 
    	and DatabaseID = db_id()
    order by
    	td.ObjectID,
    	td.StartTime
    

    Gruß Yury
    Donnerstag, 2. Dezember 2010 17:22
  • Hallo Micha,

    Wenn Du Deinen Kunden ein freies Ändern erlaubst, so wirst Du
    nicht um einen textuellen Vergleich drumherum kommen.

    Der Vergleich mit der SCHEMA_VER war aber auch ziemlich riskant.
    Funktionieren tut das nur solange ausschliesslich mit ALTER gearbeitet wird -
    verwendet man DROP ... CREATE (wie z. B. der EM/SSMS) geht das schief.

    Gruß Elmar

    Freitag, 3. Dezember 2010 09:30