Omitting Portal Records or reducing found records.

[effectsguy]

Hi all, anyone have any thoughts on this?

I have 2 related databases, related by city (in a contact list type layout) One db contains the contact info and the other is a form view of sorts, displaying all related contact info.

Currently I set it up as a portal and it's working well. I also have a check box in each record and I'd like to tell it to export (or import to another database) only those that are checked.

I can get it to export all records in the portal with no problem, but I'm not able to reduce the export set by omitting the checked boxes. So essentially I'm getting too much info.

One current way I can think of is by doing the import and then immediately having it do a find for the check boxes and delete those out. Seems like the long way about it though.

Thanks for any help!

[Vaughan]

"I also have a check box in each record and I'd like to tell it to export"

This sort of system works well when there is only one user: imagine a busy office, and several people are checking and unchecking the boxes. It's not going to work.

A smarter way is this: instead of marking the record, add the recordid to a list in a global field (each user has their own independent list) and then use the Go to Related Record script step to select the records in the list, then export.

[Fenton]

I have 2 related databases, related by city (in a contact list type layout) One db contains the contact info and the other is a form view of sorts, displaying all related contact info.

If by "database" you mean "file", I have to wonder why you don't pull it all into one file, 2 tables; especially as you've got FileMaker Pro Advanced. But that's not really the subject.

I also wonder why you'd have a form view IN THE CHILD table displaying "all related contact info." It would be more normal to have the form view IN THE PARENT table, showing multiple records of related data in a portal. The multiple records in the child table would be normally in a list view, since they are multiple. Yes, you could also flip thru them in a Form view. By why tell us explicitly it's a Form view (of sorts)? It's confusing.

Currently I set it up as a portal and it's working well. I also have a check box in each record and I'd like to tell it to export (or import to another database) only those that are checked.

You need to tell us explicitly WHICH file/table has the checkbox. Are you trying to omit some portal row records? Or are you trying to export only from checked Contacts? Two very different operations.

Also, "a check box" doesn't tell us what the values of the checkbox might be like. Is it a single Boolean value, ie., 1? Or other text?

Without the two facts above I can't really say what you should do; though I can say for sure that importing them, then deleting the ones you don't want is not necessary. I'm sure it's fairly easy to do what you need; but I cannot really understand exactly what you've got and what you want done.

[Oh, and what Vaughn said also. Which, if multi-user opens up another area which needs development. But I don't yet know which table's records need to be omitted. But if you're going to "mark for a user", you need to say how long these "marks" need to last; globals only last for one session; no exiting then coming back the next day.]

Edited August 31, 2007 by Guest

[Søren Dyhr]

I came to think of Jeff Almquists approach to deal with the multiuser aspect of the matters.

However is the unequal relation changed with fm9 - making it less usefull - it won't behave until a relevant key arrives. I had therefore to seek shelter under a CF instead:

http://www.briandunning.com/cf/230

To facilitate what I think this question is about???

--sd

StrainOmit.zip

[effectsguy]

"I also have a check box in each record and I'd like to tell it to export"

This sort of system works well when there is only one user: imagine a busy office, and several people are checking and unchecking the boxes. It's not going to work.

[color:blue]Ah to follow up, it will be set up to submit the found records, then clear out the form for the next round. There won't be a situation like you describe.

A smarter way is this: instead of marking the record, add the recordid to a list in a global field (each user has their own independent list) and then use the Go to Related Record script step to select the records in the list, then export.

[effectsguy]

If by "database" you mean "file", I have to wonder why you don't pull it all into one file, 2 tables; especially as you've got FileMaker Pro Advanced. But that's not really the subject.

[color:blue]It actually is set up that way. The end results get imported into a third table within the file.

I also wonder why you'd have a form view IN THE CHILD table displaying "all related contact info." It would be more normal to have the form view IN THE PARENT table, showing multiple records of related data in a portal. The multiple records in the child table would be normally in a list view, since they are multiple. Yes, you could also flip thru them in a Form view. By why tell us explicitly it's a Form view (of sorts)? It's confusing.

[color:blue]It's set up as a form view with the portal because I have the existing contacts in one portal and on the same page I have an additional portal to another table that will allow you to add additional people to the export that are not related. A manual entry. Both portals will need to be exported.

You need to tell us explicitly WHICH file/table has the checkbox. Are you trying to omit some portal row records? Or are you trying to export only from checked Contacts? Two very different operations.

[color:blue]The checkbox field lives in the parent table. My intent is to only export the checked box records.

Also, "a check box" doesn't tell us what the values of the checkbox might be like. Is it a single Boolean value, ie., 1? Or other text?

[color:blue]Just a 1 & 0, it's not used or displayed elsewhere.

Without the two facts above I can't really say what you should do; though I can say for sure that importing them, then deleting the ones you don't want is not necessary. I'm sure it's fairly easy to do what you need; but I cannot really understand exactly what you've got and what you want done.

[Oh, and what Vaughn said also. Which, if multi-user opens up another area which needs development. But I don't yet know which table's records need to be omitted. But if you're going to "mark for a user", you need to say how long these "marks" need to last; globals only last for one session; no exiting then coming back the next day.]

[color:blue]I forgot to mention that it will be cleared out once the export is finished.

Here's how it will be used:

Table 1 holds all contacts

Table 2 currently holds 2 portals as described above.

Table 3 is the table that contains the "additional contacts" for manual entry.

Table 4 is the final destination to receive the "checked" contacts from table 2 and all manual contacts entered into the other portal.

The idea is you go to Table 2, it shows the full list of available contacts that are related (based on a city field in table 1). But not all of those people need to be imported into table 4. You check the ones you want and only the checked contacts get imported into table 4.

I'm not as advanced as most of you, so I'm trying to figure it out best I can. I'm completely open to the proper structure if mine isn't the best way.

Thanks again.

[Fenton]

Yes, it sounds as if you've got too much structure for what you're doing. Tables 2 and 3 sound completely superfluous, redundant. If you have People, that's 1 table. Saying "portals" implies you have multiple related records for a person. Which so far you have not justified. So far all I see is: 1. People, and 2. People selected and copied for some reason (table 4).

What you are describing sounds more like storing permanent "found sets" of people. Which is reasonable I suppose. But you haven't told us the purpose of table 4, so we can't really say. It is suspicious (to me) when posters talk about "copying" large amounts of (redundant) data to another table. You need a (very) good reason to do that, as then you have the same data in 2 places, making maintenance a problem.

There are a least a couple ways to capture found sets. One would be to just store their multiple IDs in a single text field. You could capture the IDs via Copy All Records on a dedicated ID-only layout, then paste into a new record in the Found Sets table. Or other methods, using a Loop or Custom Function.

The found set could be restored in People by a relationship from the multi-line IDs to the ID in People.

Alternatively you could import all the IDs as separate records into a table, but why? So we need to know what table 4 is for.

[effectsguy]

[color:blue]Hi Fenton, thanks for the help so far. My response and further info...

Yes, it sounds as if you've got too much structure for what you're doing. Tables 2 and 3 sound completely superfluous, redundant. If you have People, that's 1 table. Saying "portals" implies you have multiple related records for a person. Which so far you have not justified. So far all I see is: 1. People, and 2. People selected and copied for some reason (table 4).

What you are describing sounds more like storing permanent "found sets" of people. Which is reasonable I suppose. But you haven't told us the purpose of table 4, so we can't really say.

[color:blue]Table 4 is a history layout. Lets say there are 50 people in each city. But only 20, or whatever number happen to show up, of the people attend a meeting that week, they get a check mark and then all the people checked get exported and logged into table 4 that shows attendance. It would work in theory by saying, show me all people from LA that are in the group. A list shows up of all the people. I go through, check the ones that attended. The person's ID along with some global info about the meeting get exported into the history (table 4). At this point, most of the time, their attendance history is viewed in their form view main contact page in a portal. That way I can at a glance see how many meetings they've attended.

It is suspicious (to me) when posters talk about "copying" large amounts of (redundant) data to another table. You need a (very) good reason to do that, as then you have the same data in 2 places, making maintenance a problem.

[color:blue]It's about 4 or 5 fields being exported or copied. The most important of course is their ID, which is how it all relates.

There are a least a couple ways to capture found sets. One would be to just store their multiple IDs in a single text field. You could capture the IDs via Copy All Records on a dedicated ID-only layout, then paste into a new record in the Found Sets table. Or other methods, using a Loop or Custom Function.

The found set could be restored in People by a relationship from the multi-line IDs to the ID in People.

Alternatively you could import all the IDs as separate records into a table, but why? So we need to know what table 4 is for.