Thanks Jack, That sounds like some good technicalities that IB can consider when reaching my bottom line request, summed up as "Get it done! Make It Happen!".

PS: I've yet to create the NFR Case, but will, soon. I'll post that case number when I get it.

If all else fails, you could access the repository and pull the fex, then run it, but this does not take into account any -INCLUDE's or EX's the fex would have.

That sounds like a good work-around Waz, albeit a bit complex for the time being. But, I just may do it in the mean time.

Good luck with the NFR, I think it is something we all would like to have.

Another way, is to make your include file be the dynamic part, not create 500 include files, then using params to say which include to use.

I'm assuming there really can't be that big of a difference in the included file, because of a variable being different.

To sharpen my suggestion,

* Normally, Client will find the referenced fex file in Content and push it to the Server as part of the request, as it does now;
* But if the file-reference contains an ampersand, Client will make arrangements for Server to pull the file from Content, once it has resolved the amper variable.

That said, due thought must be given, in the design of the Feature, to address the possibility that the -INCLUDE will be executed more than once, and the value of the amper variable may vary of the course of the run.

And the old fashioned way would be to store the fexes on the reporting server and not the repository.

An interesting note with the way that WF sends the fexes to the reporting server.

If there are many fexes with the same name but in different directories, they are named {first 6(i think) characters} + 0 to 9. If you have more, then things will go to the dark side.