Best Way to Store Find Parameters for Future Use?

[Courtney]

I tried searching for this info, but I think I may not be using the correct terminology.

I have several scripts that perform "Finds" based on user input (a date range) and then produce a report of the records that fall in that range.

The original designer of this DB stored the user input date range in a field, and then used the "replace" feature to propagate the info across all records in the range, so that he could then put the field in the report header to identify the date range of the report.

The problem I'm having with this methodology is that I'm now storing the "last modified date" of each record, and who did the modifying. It's not terribly useful to me though if all it ever reflects is who was the last person to run a report for this date range.

I tried to solve this by creating a separate "globals" table, and storing the info there, but I can't pull it back into my report layout because it's an unrelated table. I can't figure out how to relate it, since the globals table holds only one record of global values.

Maybe I'm just going at this from the wrong angle altogether, so I'm hoping to get some advice. :P

[Genx]

.... are your global fields actually stored as globals?... because if they were it wouldnt make a difference if the table occurance is related because globals are just that... global, they can be used throughout the entire database without need for any relationships... secondly, globals dont pertain to any specific record... so that globals table of yours wouldnt actually have to have even one record...though it could if you wanted...

... also, if this is for a multi user solution, you have to realize that globals are session specific.. if its not dont worry, but if it is, search around fm forums for some more info

hope this helped, genx

[Ender]

Globally stored fields are the way to go for report title things like this. Changing values in globals will not trigger the modification date/time fields as the records are not actually modified. For this reason, you need not place the globals in a separate Globals table. But if you do wish to access globals from another table, you should be able to.