Suchen & Ersetzen über ganze Datenbank

[unique24]

Hallo

Ich muss GUID`s in der Datenbank suchen und ersetzen. Leider weiß ich nicht wo überall ein Eintrag mit dieser GUID existiert.
Gibt es ein "Suchen/Ersetzen über die ganze Datenbank" ?

Danke!

[Ralf Jansen]

Nein. Such dir über sys.columns alle Spalten vom Typ uniqidentifier und den Tabellenamen und bastel dir kurz aus den beiden Daten ein entsprechendes update SQL.
Sollte mit einem halben Dutzend T-SQL Zeilen möglich sein.

[unique24]

Nein. Such dir über sys.columns alle Spalten vom Typ uniqidentifier und den Tabellenamen und bastel dir kurz aus den beiden Daten ein entsprechendes update SQL.
Sollte mit einem halben Dutzend T-SQL Zeilen möglich sein.

Hallo Ralf

Danke!
Hast du noch einen Tipp wie ich die GUID abfrage. Tabellen sind mit "sys.columns" klar.
Und kann ich diese Angaben gleich in einem update Befehl einbauen?

UPDATE "table name" Set "column name" = 'GUID new' where "column name" = 'GUID old'

Danke!

[Ralf Jansen]

Cursor über die syscolumns Abfrage bauen um an die einzeldaten zu kommen und dann kannst du per

[Highlight=SQL]SET @Sql = 'update ' + @TableName + ' set ' + @ColumnName + ' = ''' + @NewGuid + ''' + where ' + @ColumnName + ' = ''' + @OldGuid + '''';
EXEC sp_executesql @Sql;[/Highlight]

dein Update dynamisch absetzen.


Edit : Wenn die Guid an irgendwelchen ForeignKey Beziehungen beteiligt ist ... äähhhh ... Viel Spass

[unique24]

Hallo Ralf

Ok, ich sehe schon das es für einen SQL Newbie so nicht einfach möglich ist. Da sind zu viele unbekannte.
Dein SQL Code leuchtet mir zwar noch ziemlich ein, aber das ganze schaffe ich so wohl nicht. :-(

Danke!

[Ralf Jansen]

Die GUIDs hab ich noch hart codiert. Aber das sollte als Anschauungsmaterial ausreichend sein um damit zu arbeiten.

[HIGHLIGHT=SQL] DECLARE GuidColumns CURSOR FOR
SELECT QUOTENAME(s.name)+'.'+QUOTENAME(OBJECT_NAME(c.obje ct_id)) as TableName,
QUOTENAME(c.name) as ColumnName
FROM sys.columns AS c
INNER JOIN sys.objects as o on c.object_id = o.object_id
INNER JOIN sys.schemas as s ON o.[schema_id] = s.[schema_id]
INNER JOIN sys.types AS t ON c.user_type_id=t.user_type_id
WHERE t.name = 'uniqueidentifier'
AND s.name != 'sys' -- Systemtabellen noch sauber wegfiltern oder auf Schema eingrenzen
ORDER BY c.object_id_ID;

OPEN GuidColumns;

DECLARE @TableName nvarchar(255);
DECLARE @ColumnName nvarchar(255);
DECLARE @Sql nvarchar(2048);

FETCH NEXT FROM GuidColumns INTO @TableName, @ColumnName;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @Sql = 'update ' + @TableName + ' set ' + @ColumnName + ' = ''D31D4BA6-1E29-4CB6-8AA8-A65A9198388F'' where ' + @ColumnName + ' = ''D31D4BA6-1E29-4CB6-8AA8-A65A9198388F''';
EXEC sp_executesql @Sql
FETCH NEXT FROM GuidColumns INTO @TableName, @ColumnName;
END;
CLOSE GuidColumns;
DEALLOCATE GuidColumns;[/HIGHLIGHT]

[defo]

Da sich der TE als Newbie bezeichnet, sei noch der Hinweis gestattet, dass man hier sorgfältig darauf achten sollte, welche Tabellen selektiert, demzufolge aktualisiert werden. Sicherheitshalber kann man dem Nutzer, der das durchführt nur Update Rechte auf die in Frage kommenden Tabellen gewähren.
Hilfreich wäre an der Stelle m.E. auch ein Logging, das neben der Tabelle auch ID (PK), alt/neu Wert der GUID und update count(!*) in eine Tabelle oder Datei schreibt. So hat man absolute Nachvollziehbarkeit und das Ganze ist notfalls reversibel.
An der Stelle noch der Hinweis, dass man hier wunderbar mit selbst kontrollierten Transaktionen arbeiten kann. Also (implizit) Transaktion beginnen, Update Menge per Selektion(en) erfassen, Updates fahren, Ergebnis kontrollieren, Transaktion aktiv commiten oder rollback aufrufen.

Wenn alles glatt läuft ist es natürlich egal und Zusatzaufwand, andernfalls möchte ich es nicht gewesen sein.

Falls es es sich bei den GUID um PK oder FK handelt, sollte man sich zudem fragen, was in dem System schief läuft und sich bewusst sein, dass soetwas unter normalen Umständen nicht gemacht wird/ werden sollte (abgesehen davon, dass es sowieso viel aufwändiger ist).
Die Update Basis, also alte/ neue GUID kommen idealer Weise ebenfalls aus einer dafür angelegten Tabelle.
!* Nur damit weiß man totsicher, welcher Satz wie oft/tatsächlich:
0 = gar nicht, falsches Where Kriterium
1 = genau richtig
2 = ggF. ~unsauberes Where Kriterium
..
n = s.o. (erst recht)

geändert wurde.

[unique24]

Hallo

Oh, danke ... werde es mir mal durchschauen!

Der Hintergrund:
In unserem kleinen ERP Programm, werden teilweise Kontakte oder Kunden doppelt angelegt. Richtig schlimm ist es, wenn bei beiden oder mehreren schon Aktionen gesetzt waren.
Ich muss nun alle auf eine Adresse mergen.
Foreignkey hat keine Tabelle, soweit ist sehe.

Alle Angebote und Informationen im ERP haben als Referenz die GUID der Adresse.

Danke!