I am Berke

Sokszor találkozom olyan adatbázisokkal, amikor semmilyen vagy nagyon rossz dokumentáció áll rendelkezésre. Ettől többször fordul elő, hogy az alkalmazás által használt értékek adatbázisból jönnek, de még a Profiler sem biztos, hogy jó megoldás annak megfejtésére, hogy honnan is jön az adat, ráadásul sokszor időrabló feladat megtalálni egy-egy értéket. Sikerül mindig belenyúlni a jóba :)

Ma pl egy GUID-ot kellett megkeresnem egy nem dokumentált adatbázisban, és csak annyi volt a feladat, hogy egy adott GUID, melyik táblában, mely oszlopában van benne. Lehet nem a legoptimálisabb megoldás, de egy 30 GB adatbázison ahol 200+ tábla van elég gyors volt. Persze ezen azért az is segített, hogy indexelt oszlopokról volt szó...

DECLARE @SCHEMA sysname;
DECLARE @TABLE	sysname;
DECLARE @COLUMN sysname;
DECLARE @STMT	nvarchar(max);

DECLARE @searchtype sysname 
SET @searchtype = 'uniqueidentifier';
DECLARE @searchstring nvarchar(max) 
SET @searchstring = '5AAB6B0E-26C9-4CC2-8716-0002DEF859AA'

DECLARE SEARCH CURSOR FOR
SELECT
	SCHEMA_NAME(O.[schema_id]),
	O.[name],
	C.[name]
FROM
	sys.objects O
JOIN
	sys.columns C ON O.[object_id] = C.[object_id]
JOIN
	sys.types T ON C.[system_type_id] = T.[system_type_id]
WHERE
	O.[type] = 'U'
AND
	T.[name] = @searchtype
OPEN SEARCH;
FETCH NEXT FROM SEARCH INTO @SCHEMA, @TABLE, @COLUMN;
WHILE @@FETCH_STATUS = 0
	BEGIN
	
		SET @STMT = N'IF EXISTS (SELECT 1 FROM [' + @SCHEMA + '].[' + @TABLE + '] 
						WHERE [' + @COLUMN + '] = CAST(''' + @searchstring + ''' AS ' + @searchtype + ' ))
						BEGIN
							SELECT ''[' + @SCHEMA + '].[' + @TABLE + '].[' + @COLUMN + ']''
						END';
		EXEC(@STMT);
		FETCH NEXT FROM SEARCH INTO @SCHEMA, @TABLE, @COLUMN;
	END
CLOSE SEARCH;
DEALLOCATE SEARCH;