merging found sets????

[jackdaw]

Hi all

I'm hoping you can help out...

I've got 2 databases - each containg list of people going to various
events

one database is members of the club, the second is of their guests
info

I want to do a search based on the event number, held against each,
and return a list of all members and guests who are booked to come on
that event, and print it out

obviously doing a search on each database and creating a nice layout
in each database seperately is easy, but what I really want to do is
combine the 2 found sets into a single page for printing

and because the returning lists are going to vary in length portals
dont seem to help

the only way I can think of doing this is a rather long winded export
and reimport sort of solution, and there MUST be an easier way that
I'm missing

any ideas?

jackdaw

[test@test.text]

I think that reoganising your data could help.
Put all people in 1 database (extra field to identify member/guest)
Put all Events in another db
Create a new db where you link event to people.
hope this helps
[email]Rob@infortica.be[/email]

"jackdaw" <yak@globalnet.co.uk> wrote in message
news:kic5nvcu4lu06fbpriibg8ivq5fv950g4q@4ax.com...

> Hi all
>
> I'm hoping you can help out...
>
> I've got 2 databases - each containg list of people going to various
> events
>
> one database is members of the club, the second is of their guests
> info
>
> I want to do a search based on the event number, held against each,
> and return a list of all members and guests who are booked to come on
> that event, and print it out
>
> obviously doing a search on each database and creating a nice layout
> in each database seperately is easy, but what I really want to do is
> combine the 2 found sets into a single page for printing
>
> and because the returning lists are going to vary in length portals
> dont seem to help
>
> the only way I can think of doing this is a rather long winded export
> and reimport sort of solution, and there MUST be an easier way that
> I'm missing
>
> any ideas?
>
> jackdaw

[Howard Schlossberg]

The first best way of doing this would probably be to have a third file
import from both and then print the combined report.

The portal won't work unless you're okay with guests being sorted with
their hosts. But if everyone is supposed to be in alphabetical order
mixed in with each other, then a portal won't work.

jackdaw wrote:

> Hi all
>
> I'm hoping you can help out...
>
> I've got 2 databases - each containg list of people going to various
> events
>
> one database is members of the club, the second is of their guests
> info
>
> I want to do a search based on the event number, held against each,
> and return a list of all members and guests who are booked to come on
> that event, and print it out
>
> obviously doing a search on each database and creating a nice layout
> in each database seperately is easy, but what I really want to do is
> combine the 2 found sets into a single page for printing
>
> and because the returning lists are going to vary in length portals
> dont seem to help
>
> the only way I can think of doing this is a rather long winded export
> and reimport sort of solution, and there MUST be an easier way that
> I'm missing
>
> any ideas?
>
> jackdaw

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California
Associate Member, FileMaker Solutions Alliance

[jackdaw]

On Thu, 25 Sep 2003 08:26:05 -0700, Howard Schlossberg
<howard@antispahm.fmprosolutions.com> wrote:

>The first best way of doing this would probably be to have a third file
>import from both and then print the combined report.
>
>The portal won't work unless you're okay with guests being sorted with
>their hosts. But if everyone is supposed to be in alphabetical order
>mixed in with each other, then a portal won't work.
>

so an in-elligant export + reimport seems to be the way to go with
this

thanks guys

[Glenn Schwandt]

Rob is probably correct, you should have one database for all people, with
fields to identify what kind of people they are. One field for member or
guest, and possibly another field for guest records to hold the ID of the
member they are associated with.

One way to do this with separate databases as you describe could be to use
conditional value lists to assemble the names based upon the event. In the
members database, create two relationships based upon the event field on
both sides, one to the members database (self-relationship) and then one to
the guests database. Now create two value lists (named "Members" and
"Guests") in the members database that use values from the name field, using
one of the two relationships you just created as filters as appropriate.
You can then create an unstored calculation field to massage these lists
into the format you desire. Something like this could work for you:

Attendees (calculation, text) = "Members: " & Substitute ( ValueListItems
( Status ( CurrentFileName ), "Members"), "¶", ", ") & "¶¶Guests: " &
Substitute ( ValueListItems ( Status ( CurrentFileName ), "Guests", ", ")

"jackdaw" <yak@globalnet.co.uk> wrote in message
news:kic5nvcu4lu06fbpriibg8ivq5fv950g4q@4ax.com...

> Hi all
>
> I'm hoping you can help out...
>
> I've got 2 databases - each containg list of people going to various
> events
>
> one database is members of the club, the second is of their guests
> info
>
> I want to do a search based on the event number, held against each,
> and return a list of all members and guests who are booked to come on
> that event, and print it out
>
> obviously doing a search on each database and creating a nice layout
> in each database seperately is easy, but what I really want to do is
> combine the 2 found sets into a single page for printing
>
> and because the returning lists are going to vary in length portals
> dont seem to help
>
> the only way I can think of doing this is a rather long winded export
> and reimport sort of solution, and there MUST be an easier way that
> I'm missing
>
> any ideas?
>
> jackdaw

[jackdaw]

On Thu, 25 Sep 2003 10:55:47 -0500, "Glenn Schwandt"
<schwandtgat@aoldot.com> wrote:

>Rob is probably correct, you should have one database for all people, with
>fields to identify what kind of people they are. One field for member or
>guest, and possibly another field for guest records to hold the ID of the
>member they are associated with.
>
>One way to do this with separate databases as you describe could be to use
>conditional value lists to assemble the names based upon the event. In the
>members database, create two relationships based upon the event field on
>both sides, one to the members database (self-relationship) and then one to
>the guests database. Now create two value lists (named "Members" and
>"Guests") in the members database that use values from the name field, using
>one of the two relationships you just created as filters as appropriate.
>You can then create an unstored calculation field to massage these lists
>into the format you desire. Something like this could work for you:
>
>Attendees (calculation, text) = "Members: " & Substitute ( ValueListItems
>( Status ( CurrentFileName ), "Members"), "¶", ", ") & "¶¶Guests: " &
>Substitute ( ValueListItems ( Status ( CurrentFileName ), "Guests", ", ")

yeah, sorry, the solution is actually a tad more complex than I may
have intimated

the whole solution uses about 12 databases to hold various sets of
abstract data, which are linked by varying common fields, but each
database has it's own functions, so there is good reasons for all the
separation - honest ;)

there is a database that holds the list of member ref numbers booked
onto an event (again held by ref number only) and there is a seperate
database of member details, as well as another one for guests (and
several more beyond that :) )

so what I do is search the database which is holding the bookings
based on the event number, and use the found member numbers to do
related database finds for the members details held in another
database - which is all fine

there is another database that contains the guests (the reason for
having 2 sperate databases holding this info was to make the
booking/cancellation and other functions less complicated to code)

I can then search this second database, again based on event number,
and get the guest details directly

what I really wanted to do was have a solution that was like portals
to do this, but the problem with using portals is that they are set to
a fixed number of rows at creation, and also cant do the relational
lookup stuff I need

it's beginning to look like I either have to write an export/import
routine for this, or else rethink how some of the data is held

thanks for all the feedback guys

jackdaw