"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:<3Jidnec-iZpyCIfdRVn_iw_at_comcast.com>...
> ever have a complex statement that works just fine in development and test
> but once you get it into production returns duplicate rows?
>
> had to figure one of those out last night, and the more we locked at the
> statement and examined the data, the more our heads hurt
>
> this morning i remembered a quick way to determine what table is
> contributing to the extra rows:
>
> we simply added the rowid of each table to the select list, and within a few
> minutes saw which table was returning too many rows by looking for changes
> in rowid without changes in data -- a whole lot easier than digging thru the
> data and doing extensive rewrites to progressively eliminate, or buildup,
> joins
>
> -- mcs
Mark, I guess that is about the same as returning a constant to
represent the table and has the advantage of allowing you to zero in
on the rows in doubt. I like to add a constant that represents the
table to view definitions that use a union all instead of a union
where the same row should not exist in both source sets. Now and then
what should not happen, does.
Received on Sun Feb 01 2004 - 16:02:54 CST
