This is by no means a small table. I don't know how big do you need your table to be, but mine seems pretty big...

As far as the documents resistance to "corruption", well, no idea. I only once experienced corruption in a Word document, and it was such a long time ago that I don't remember when. Keep in mind that I have 100s of Word documents, and that I wrote my 250p Masters and started my 500 pages PhD with Word -- and with many tables, graphics, etc. And... I use a laptop

The biggest document I have on my HD is a social science book I had to scan a long time ago. It contains columns and tables, heavy formatting everywhere, etc. It's 527p long -- the book was actually 1022 p long. It's not corrupted yet and I've used it a lot (underlined, highlighted, commented, etc.).

As far as formatting and styles goes : if you work in IQ anyways to generate your index, working/editing in Word isn't probably be what you'll be doing most of the time. You'll basically end up 1- exporting 2- formatting using styles. Which is very easy when you've got a table since you can select a full 99 pages column and... Apply a style. It takes a 2-3 second on my very average laptop (just tried it)

But of course this depends on the complexity of the needed formatting.

Keep in mind though that IQ generates lots of columns at the right. Those need to be selected and deleted for easier table manipulation. I have no idea why these are there.

I have used the html export feature, but is that the "best" way of putting it into a Word document? I make a point of this, because this is the first time I'm using Word the "right" way with styles, templates, fields, etc.

I have used the html export feature, but is that the "best" way of putting it into a Word document? I make a point of this, because this is the first time I'm using Word the "right" way with styles, templates, fields, etc.

Interesting. I'll have to try that tomorrow. incidentally, when I have carriage returns in one of the cells in my grid in InfoQube, when I export it in anything besides HTML export, those carriage returns become a new line or cell, which makes sense, I suppose. The problem is that it adds blank cells under the cells next to it to make it all fit. The problem with that is when you use it to make a table, it messes up all the grid border format, because all the blank cells get borders also. If there's a way around it, that would be nice. I can't think of a good solution.

Interesting. I'll have to try that tomorrow. incidentally, when I have carriage returns in one of the cells in my grid in InfoQube, when I export it in anything besides HTML export, those carriage returns become a new line or cell, which makes sense, I suppose. The problem is that it adds blank cells under the cells next to it to make it all fit. The problem with that is when you use it to make a table, it messes up all the grid border format, because all the blank cells get borders also. If there's a way around it, that would be nice. I can't think of a good solution.

I wasn't trying to come up with any comprehensive list, only tossed out a few things that came to mind after reading the posts. My "knowledge" is based on what I have found useful. In any event, I've used tables extensively in Word, and "tables" extensively in Excel. My successful experience with both is making it difficult to persuade me that there is any validity to the idea that tables should rarely if ever be used in Word. I'll listen to the arguments, but so far they are not consistent with my experience, which is that tables in Word are often handy, useful, and the right tool for the job.

Word tables can be handy for entering data or for composing/designing when you know you will have some kind of row/column setup but not sure what the final layout will be. The kind of thing I have in mind would be tedious using tabs (which most definitely have their place - tables aren't always the best tool).

Word was never designed for final layout inline with composition anyway, so this really is something of a non-issue. If you create the data, then apply formatting, you are following the workflow Word was designed for. If you are creating the layout and then filling in the content, tables are much more efficient, and that is the way Excel is designed and should be used - hence my statement about using the correct tool for the job.

Not sure you and I are talking about the same thing here. When I say compose, I mean something from scratch, all sorts of different things. If I am manipulating primarily text - text that I am writing, importing, or both - nine times out of ten I will find Word to be the more suitable tool, Excel only rarely.

Re "Word was never designed for final layout inline with composition..." , what do you mean by "final layout inline with composition?"

What happens when you copy that table from Excel and simply paste it into Word?

And when you talk about "headers" I only see the one (Item Description) at the top of your sample. I assume there are others since it's easy to make the first row/rows of a Word table repeat at the top of each page.

What happens when you copy that table from Excel and simply paste it into Word?

And when you talk about "headers" I only see the one (Item Description) at the top of your sample. I assume there are others since it's easy to make the first row/rows of a Word table repeat at the top of each page.

When I paste from Excel, it seems to work fine. I haven't had any problems yet. From the articles, it seems like you get more problems when you edit the table within Word (move cells, add rows, columns, drag drop text, etc.) So now I'm doing everything in Excel and then copy/paste to Word. It's easier in Excel anyway.

I didn't know about this headers on top of each page. I'm going to do that!

superboyac, I wonder what the data looked like originally, the data you imported. Because when I look at the example you posted, my first thought is Word. This just looks like a natural for a Word table, right from scratch. And the fact that these are not one-line records would make tabs the wrong tool here imo. Plus as soon as you want borders around the cells, tabs stop being convenient.

The stuff they talk about in the article, I have run into that sort of problem. In general the bulk of the problems seem to happen when you are copying and pasting cells (as opposed to just the text). When there are no merged cells (problematic in both Word and Excel and worth avoiding), I usually don't have problems moving/adding/deleting/copying/sorting whole rows or columns. Tried a table within a table once or twice, never again. Merging tables has at times caused major headaches.

I do serious and extensive version saving/backup while I'm working and check carefully that things are ok before I press on. Mutters heard often from my corner: "shouldn'ta done that, sure glad I saved a version just before I tried it."

Unless they work in Word 2007, not a table style!!! If it doesn't import as a table, import it as tabbed data. Then turn it into a table (Table>convert>...). Once it's a table, then apply paragraph styles column by column (usually everything in a single column has the same basic format). Select a cell's contents, make it pretty, name a style after it. Select the whole column (and any other suitable columns) and apply that paragraph style.

btw, Word stores paragraph formatting in the endPara mark (the pilcrow). If you have the cursor in the paragraph, with nothing selected, then any paragraph style you apply will automatically be applied to the whole paragraph (same as if you selected the entire paragraph including the endPara mark). If you select part of the paragraph, which also includes the scenario where you select everything except the endPara mark, then the style will be applied as a character style, not what you want. (Remember the difference between including and not including the endPara mark when you select and copy. When pasting into another document this will determine whether or not the style also gets pasted. Experiment.)

The thing about table cells: they are paragraphs without endPara marks. I think the little shaded square that appears at the end of cell text, when you show formatting marks, serves the same purpose.

You can use end para marks in a table cell, but I usually use line breaks if I want to force a newline. That way everything, both sides of any line breaks, is still all in the same paragraph.

Export to HTML and copy to Word. This works even better now as the "multiple empty columns to the right of the page" problem is now fixed (it was a problem with how Word interpreted HTML).

Then do exactly as AndyM suggested :

Once it's a table, then apply paragraph styles column by column (usually everything in a single column has the same basic format). Select a cell's contents, make it pretty, name a style after it. Select the whole column (and any other suitable columns) and apply that paragraph style.

When you need more than one line per record is when I stop looking at tabs and start looking at tables.

I suppose you could have several types of "lines" (actually one-line paragraphs). One line would be set up with a style (styles include tabstops) to always be the first line in a "record", the other(s) to be the second, third, etc, with different tabstops if you wanted the second line indented, etc.

But then your records would be multiline and multiparagraph, which would make sorting (manually or automatic) a nightmare. For me, generally in this scenario a borderless table would be the right tool for the job.