kassetra

Oh yeah, Copy All Records! Forgot about that step... The way I was thinking of works... and it works every time, no matter how many criteria... because each time new sets of criteria are added, it becomes a subfind of the current found set... I can find Parents that have Red Haired, Green Eyed, Primary School age, born in September children *AND* that also have Blonde Haired, Brown Eyed, Secondary School age, born in April children but *NOT* Blonde Haired, Brown Eyed, Secondary School age, born in April, that have a twin....and on and on it goes... when all I really want to find are the *Parents* of said children -- not the children themselves. And with the third database keeping track of the find criteria -- I can allow my users to "save" their find criteria (especially for very complex finds). It *can* be a tad slow over the network, but this is a local developer copy and not the server production copy... so it should be better when I move it into production.... That being said, I'd like to see other ways of maybe handling this information (more elegantly, hopefully), so yeah, I'd like to see that clone! Thanks again!

I think I have it -- after thinking about condensing the search into a calculated field....I finally thought of something straight forward -- I need to do each subsequent find inside the previous found set -- a subfind. Your calculated fields idea reminded me that I could "save" the Parent ID's from the previous found set (which is what I'm actually searching for -- the Parents!) If I want to find parents that have both, Red Haired children and Blonde Haired children -- First I do a find for the Red Haired children. I put all of the found Parent ID's into a global field (loop...set field, etc.). Then I do a find for the Blonde Haired children -- Now, I compare their Parent ID's to the global field. If there is a matching Parent ID -- I put an "X" after the matching Parent ID in the global field. After I finish checking for the last record, I "clean out" the global field of any Parent ID that *doesn't* end in an "X". If Blonde Haired children was my last criteria, I use the global field to find all of the Parent records in the Parent db -- if it wasn't, I do a new find and compare Parent ID's again. (the "NOT" operator would have the opposite effect -- if there is a match, put an "X" after it, and then *remove* all of the "X" fields!) I'll have to see how efficient this idea is....

Hmmm. Maybe I can adapt that with my "clean up" scripts to find what I need. Those calculations work on a single record, and if I was looking for all of the red haired-green eyed children and all of the blonde haired-blue eyed children, that would be marvelous! The catch is that I want to find all of the red haired-green eyed children *AND* the blonde haired-blue eyed children that come from a *single* parent. (each parent that has both: at least one red haired-green eyed child *AND* at least one blonde haired-blue eyed child -- it gets worse when I start to throw the *NOT* operators in there as well). That's where I have my problem. Maybe by condensing the criteria though, as you have suggested, my "clean up" scripts that run for an "AND" or a "NOT" logical operator would work better. I'll chew on that thought for a while and see if it makes this work better. Thank you for your ideas!

I have a Parent db where each record can have more than one related record in my Child db. I would like to be able to find Parent records by criteria in the Child db. For example, let's say my child database has these three fields: Hair Color Eye Color Birth Month And that each record in the Parent database, may have many related records in the Child database. Sounds simple, except that I never know what the criteria will be. One minute my users may need to find the Parent db records that have related child records with: Red Hair, Blue Eyes, born in September *AND* Blonde Hair, Green Eyes, born in December -- and in the next minute they may need to find Parent records that have related child records with: Brown Hair, Brown Eyes *AND* Blonde Hair, Brown Eyes, but *NOT* Brown Hair, Brown Eyes born in August. I have a third "Find" database that allows my users to input each set of criteria into a portal (so that the last example of Brown Hair / Blonde Hair children would have three records -- one for each criteria)... that then goes out and "finds" the child criteria...but finding parent records (by ID number) that meets all of that criteria is rough. I have some clumsy scripts that go through and "clean up" after what is essentially an "OR" find in the Child database, and then translates the unique Parent record ID numbers to a global -- which then finds the Parent records in the Parent db. But it doesn't work well -- especially when I never know how many *AND* or *NOT* operators my users will need (the clean up scripts usually bork on me when I have *both* an *AND* and a *NOT* in my criteria). I've tried running the first criteria as a regular find, and then extending or constraining the remaining criteria -- but that doesn't work if, for example, your first find is all Brown Haired children, and then you want to constrain your records to only include Brown and Blonde hair. So I can extend the found set to include Blonde haired children... but then how do I constrain the find to only Parent ID numbers that have *BOTH* Blonde and Brown? The "!" operator doesn't work using the "Constrain" option... I keep trying it though... If anyone has a fresh perspective on how to make this find for my users, I would be most appreciative. I've been stuck on this project for over a month. I'm sure there has to be a more elegant solution, I'm just running out of time to think of it on my own.

If your "prior entries" are included in the range of your report, you can create a simple summary field to give you a beginning balance. I suspect, however, that you want to see a report for a specific range, and that the records that happened prior to that range you want to use as your beginning balance; if this is the case, there are a few ways you can accomplish this task. Here is a way I might try (you will need to write a script(s)): Fields: 1. Create a summary field that points to your balance field. 2. Create some global fields: beginning date, ending date, beginning balance, ending balance. (if you don't already have them) Script: 1. Store your date range beginning and ending dates in two global fields. 2. Do a find for all dates prior to the beginning date. 3. Set the beginning balance field to the summary field. 4. Now do a find for your date range (between beginning and ending date) 5. Set your ending balance = beginning balance - summary field. 6. Display on your report. hopefully that works for you.

What kinds of criteria are you trying to save in your scripts? When you run the scripts the next time -- how is the output different? Do you have some samples you can show?

As a quick fix, you can make a hidden layout that has boxes filled with your special colors, and then jump to that layout and add your colors back to the table by choosing your squares and adding their custom colors to the table. That's what I do, and I have hundreds of special colors.