Hi =?Utf-8?B?bnljZG9u?=,
The multiple tables in doc do all need to be transferred.
How can I tell if a cell has been merged?
If you don't know what you're going to be getting, then that can be very
tricky. Best, really, is to "walk" the table, counting how many cells in each
row / each column. Timewise, this is expensive...
Some 'memo' type Cells do contain paragragh/line breaks.
OK, this is a bit easier to handle.
Transferring tables: there are basically two approaches that can be used. One
is to "walk" the rows and columns. This is very slow.
Faster is to first convert the table to delimited text format (check out
Table/Convert/Table to text to get a feel for this). This can then be read
directly into a string variable, which can either be
- written to a file, then imported into the database
- "split" into an array for further processing (i.e. read into a record
set)
The tricky part is that you'd need to use Find/Replace in Word to replace all
the paragraph marks in the table with some unique character, so that when the
table is converted to text the structure is maintained. Word always uses a
paragraph mark (Chr(13) = vbCR) as the record delimiter). Once you have the
data in a string variable, you can use the Replace function to replace that
unique character with a vbCRLF (what Access uses for a new line).
Yes, column headers - though do not correspond to Access table. Figured I
could map to applicable Access table once I get raw data into Access, using
Update or append queries. (much more astute in Access than Word)
Yes, that would work, as long as you know the things to map. I would imagine,
if you know this, you should probably also know whether the table contains
merged cells?
how might I approach in ADO or DAO?
DAO is Access's native database "language". you'll find it discussed in most
books on Access programming and it's fully documented in the Access Language
Reference ("VBA Help"). Look up terms such as CurrentDatabase, Recordset,
Field and you should get the basics. You can also use it to run Queries
(Update or Append queries, for example); you can even create and run them
"on-the-fly" if you need something more dynamic.
ADO is the interface language for OLE DB; think of it as the successor to
ODBC. It's database-independent, meaning you can use the same code for any
database, the only thing that you'd need to change would be the connection
string for connecting to the database you want to use. ADO supports running
Update and Append SQL directly on the database (IOW not using a Query stored
in Access).
Given your background, unless you think the entire tool (database and Word
table conversion) would once be moved to something like SQL server, I'd say
DAO would be the better choice. My advice would be to ask in an ACCESS
newsgroup for detailed help on the syntax. I'm sure the folks there can point
you to articles and tutorials.
Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org
This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail