|
|
Posted by Erland Sommarskog on 10/22/05 17:23
--CELKO-- (jcelko212@earthlink.net) writes:
> Please post DDL, so that people do not have to guess what the keys,
> constraints, Declarative Referential Integrity, data types, etc. in
> your schema are. Sample data is also a good idea, along with clear
> specifications. It is very hard to debug code when you do not let us
> see it.
>
> What you did post makes no sense. There is no consistent definition of
> these tables, since the coumns change from month to month. You cannot
> compare them at all.
Depends on exactly which columns he puts in, on how much he want to compare.
I have actually been playing this game recently. I've been running traces
at some customer sites, and to anaylse the trace, I say:
SELECT ...
INTO trc1024
FROM ::fn_get_trace_table(...)
Thus, each trace gets a new table. Partly this is out of laziness, but
it could well be that the tables are different, if I decide to include
another column in the trace.
If I wanted to compare data over several days, this would be a difficult
setup to work with. But typically I'm mainly interested in the most recent
trace file, and the worst performance hogs in this trace. If I want to
compare data over several days, I can run a SELECT from a couple of tables
(rarely more than 3), since I'm usually only interested in one procedure
in such case.
The bottom line: don't do more work than you have to do!
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
Navigation:
[Reply to this message]
|