If you are planning to use Webpart connections to transfer the data  between the
webparts it won’t work. You can use SPD to connect webparts that aren’t
located on the same page, but you can only connect with webparts that are
located on a page in the same site. If you use the object model you would need
the same trust  level on web  App A as on App B. Remember that webparts don’t
actually store data, they are a User Interface into another datasource.

Well, I thought that's what CQWP's did. Don't they do
lookups on the data  contained in other web  parts such
as custom lists?

Actually, CQWP's do lookups against lists and libraries not webparts. I find
that a lot of people confuse a list and the ListView webpart that displays the
list. The webpart only displays the data, you have to go to the list to get the
data unless a web  part connection is available.

I think CQWP uses XML webservices to actually access  the data. Also, the CQWP
is located in the GAC and runs with Full Trust no matter what Trust Level the
Web App is running at.

OK, I guess it's a matter of semantics then. I
consider lists and libraries to be web  parts as well.
It sounds like the CQWP will work for me. Do you know
if the CQWP can perform compares against more than one
data source? I'd like to use a BDC display as one
sort and then a custom list as the seperate sort and
only match for duplicates.

> OK, I guess it's a matter of semantics then. I
> consider lists and libraries to be web  parts as well.

Perhaps you also consider a web page as a database, because it displays
information from a database. When you go to manage the web page, however,
you will find that database tools don't work.

Yes, it's a question of "semantics" -- the study of meaning in language.
Your approach simply obfuscates the meaning of the practical language we
need.

And this provides value how? I was merely responding to the
statement that web  parts cannot contain data. Document Libraries
and Custom lists are web parts  and they contain data. What's the
issue?

They aren't web  parts. They are presentable in web parts, but they
aren't web parts; they're lists. That's the issue - your semantics
are incorrect.

I apologize for the confusion then. I've always been told that while acting
under different rules, that document libraries and lists were still web  parts.
I'm guessing that the thread dying is probably because everyone realized I had
no idea  what I'm talking about.

Joshua, if my comment seemed snide then I apologize for that as well, as that
was not my intention.

Just to try to clarify this common misconception. Every visible
instance of a library or list is indeed a listview webpart. These are
used on the main page of the site and the edit, create, and list pages
that allow you to add/modify/list data  to the list or library. But the
data is stored elsewhere. The listview webpart provides a way to see
into the datastore. Unless a webpart is designed to pass data on
through a connection they are only a means of displaying data. This
becomes a critical distinction when we use the Content Query web  Part to
aggregate data from a variety of lists. Although you can aggregate the
data you can only display it using the CQWP's capabilities. You can't
use the CQWP as a datasource in and of itself. That's why you can
create an aggregated Events list using the CQWP but can't display it as
an actual Calendar. The CQWP doesn't have that capability and you can't
have it aggregate the data and then pass it to a dataform webpart
because its just a webpart not a data source.

Once again, you have provided a clear and deep, yet
concise, explanation.

Mark, I very much appreciate your apology. I realized after sending that my
remark had an argumentative tone. I apologize for that. This group is so
helpful, and its friendliness is part of its helpfulness. I'm glad we've
recovered from that momentary slide.