> Here's the rest of the story. I reduced the view to two selects. Each
> should return 250 rows. When executed independently of the view
> they return the correct count(*). When included in the view the first
> returns the correct count, the second 499; doesn't matter _which_
> is first . I used literals in the view ('d' and 'c') to identify the
source
> of the row. The view definition is below.Ben: I trust the fact that OfficeID and MemberID have switched places in the two views is part of the design? Have you tried create two separate views (V1 and V2) and then doing SELECT * FROM V1 UNION ALL SELECT * FROM V2? That ought to eliminate any possible confusion in the UNION part of the view. As David pointed out, you could reduce this SELECT to a single table SELECT with a slightly longer WHERE clause and a little bit of IFEQ logic in the first two columns if you need to swap the OfficeID and MemberID for the M records. -- Larry ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
