Larry, > I trust the fact that OfficeID and MemberID have switched places in the two > views is part of the design? Yep > 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. You're probably right, but that doesn't speak to the cause. I use unions a _lot_ and would like to know that I'm using them correctly. It looks like I'll have to exclude "all" from the union operator as a matter of course.
> 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. See my response to David. Thanks, Ben Petersen > ================================================ > 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/ > ================================================ 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/
