Thank you Jeff for looking at the code and I like your solution.

This is Old code and is just an example that code interface was driven from within Excel with VBA and SQL backend. The Grid_Table was Cell references with specific data being returned (various types). The User could select from a series of datasets over several years and or by month. The Application generated up to 80 individual outlet results (same model) with Dashboards and X tabs all generated.

The user requests blocked in XML and the returned Grid_table populating the various models.

The App used worksheet templates and built up WorkBooks dynamically for each outlet.

One of the problems was the original code (written as per your aproach was it ran to slow and would time out. Microsoft have built the macros for Pivot etc but they are course using dynamic code behind these!

You can beat the # and ## temps for speed.

That code runs like lighting.

The App used a single Proc interface (only one there was no other route permitted) The XML used to pass complex User Data details and requirements. These treated as a Table. The single Proc interface off loaded the requests to various sub Procs and then returned the datasets back to Excel.

Audit tracking was automatically built into and recorded within the DataBase.

This approach easily facilitates replacing the frontend with a Browser interface and Javascripting. Json replacing XML and Datasets is straightfoward.

Microsoft uses these temorary tools themselves.

The Microsoft PIVOT and UNPIVOT can only work using dynamic code if you think about it! But there's is a generic approach an sometimes you can write better code yourself.

Notice this isn't hidden code on the contrary the client could see the logic and maintain it for themselves.

Objects and classes with Functions and Procs is a better approach to SQL interface (IMO).