I heard a lot about not using globals, but I am still finding cases where they seem to be the best, sometimes only, solution. I have included an example of a current case.

I am attempting to setup a report, or series of reports, based on the chosen expiration month and year stored in the center table. The only other way I see to do this is to filter each table as a display that particular report.

Any thoughts or suggestions?

Bill

Are you not repairing a severe entity duplication here? You need to explain why the data is put in so many different tables, logical chunks doesn't always translate to individual tables, if a single attribute can make distinction... in a table called say "Contracts"

Something in the vicinity of this:

http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html

...if you subscribe?

--sd

Thanks for the reply.

The reason for the separate tables is the "Trade" types are different enough to require substantially different fields. At least, from I can figure out.

One another reason this seems to work better is one these tables has almost a hundred times the number of records as any of the others.

If there is a better way to do this, I am all for it. As you can well imagine this complicates everything quite a lot.

Bill D.

I would say to hell with the size of the stored data, what you might not get is that what's individualized from table to table instead should be broken out this way:

http://fmforums.com/forum/showtopic.php?tid/193285

The wouldn't make much sense in you original reporting suggestion anyway ... so what I suggest is to break data differently: Classification Vs. Organization

Build one table called trades and then the fields needed for the individual types should be a field substituting the label in the entity duplications, and the other field be the data.

--sd

Thanks,

I'll try that.

Bill