...couldn't find a posting for my kind of problem, so forgive me if one exist - or better tell me where I can find it

I try to narrow down new entries in a portal by what was entered before into the last row of another portal. In fact, I got a text database that shows different portals to other files (like contacts or projects). When I match a text to a contact (as step 1) then just the projects related to this specific contact should show up in a VL when I match the text to a project (as step 2).

This works well, but the problem is, if a contact has no related project (coming from a bridge file) of course no VL exists.

So what I try to find is something like a condition, that in that case the VL should consist of all existing projects. As I couldn't find a workaround to use 2 different VLs on one field, the right way could be to populate the fields used in the VL in a conditional way...but unfortunately I have to use a calculation field containing data from a related tabel - that means the calc field cannot be indexed and therefor not be used in a VL...

sounds complicated, doesn't it? Any ideas?

...couldn't find a posting for my kind of problem, so forgive me if one exist - or better tell me where I can find it

I try to narrow down new entries in a portal by what was entered before into the last row of another portal. In fact, I got a text database that shows different portals to other files (like contacts or projects). When I match a text to a contact (as step 1) then just the projects related to this specific contact should show up in a VL when I match the text to a project (as step 2).

This works well, but the problem is, if a contact has no related project (coming from a bridge file) of course no VL exists.

So what I try to find is something like a condition, that in that case the VL should consist of all existing projects. As I couldn't find a workaround to use 2 different VLs on one field, the right way could be to populate the fields used in the VL in a conditional way...but unfortunately I have to use a calculation field containing data from a related tabel - that means the calc field cannot be indexed and therefor not be used in a VL...

sounds complicated, doesn't it? Any ideas?

This is the opposite? of the problem I am having with a 'shrinking' or 'dwindling' list.

Try looking for dwindling in this forum and see if that gives you some insight.

It's multi-relational and multi- value list based.

I am still struggling with the concept, but have achieved what you need as an error in my relationships so am pretty sure it will work.

HTH

This is the opposite? of the problem I am having with a 'shrinking' or 'dwindling' list.

Try looking for dwindling in this forum and see if that gives you some insight.

It's multi-relational and multi- value list based.

I am still struggling with the concept, but have achieved what you need as an error in my relationships so am pretty sure it will work.

HTH

Thanks for the hint but frankly all this sounds pretty confusing...

The good thing is that my problem doesn't exist anymore because my boss just mentioned that this is exactly what he wants the database to do!

So no 2nd option to implement...

St.