Quote:
Originally Posted by epid011
We want each cell to have an ID # so that in case a new row gets inserted into a table in the future, none of the existing cell references would have to be changed.
|
Maintaining tables with hard-coded cell references that might not reflect their true addresses creates an unnecessary maintenance headache.
I recommend that you accept that the data outputs might occasionally need to be modified to reflect changed reporting requirements. Might I also suggest that you output the data in a more compact pipe-delimited format that could be parsed quite easily without the need for cell references.
With the attachment, I've merged your two tables numbered 3.3.6.1.1 into one and have bookmarked it 'Table_3_3_6_1_1' (a more meaningful name might be better, so the code doesn't get tied to an out-dated table index #). I've also included a suggested data file for a macro to process - plus the code to do so. Simply copy the document & data file to the same folder, then run the macro. As constructed, the data file contains all the cell data from your post, plus some dummy data for the 2nd tertile, for which you apparently require nothing as yet for 'IV BP only'. The data file accommodates that with what is essentially an empty line. The data file contains one line per table row. It also accommodates the addition of new lines and having data for multiple tables in the same data file (you could data for a table bookmarked 'Table_3_3_6_1_1A' and for another table, bookmarked 'Table_3_3_6_1_1B', for example). The code (updated) allows for table rows to have different column counts to populate, even within the same table.