Odd behaviour merging text with CHR(13)

P

PaulSilverman

Help, I am trying to merge contract information from a database.
Some "fields" contain "return" characters, or "paragraph marks" i.e. CHR(13)
What I find is that if the field in the merge template is in a table and has
no paragraph mark underneath it, all the "return" characters appear as
squares and the text runs together.
i.e. []15/08/2005 to 14/08/2006 exclusive - []15/08/2006 to 14/08/2008
non-exclusive - note in second excl/non excl period[]

If I add a "return" character to the end of the text, it all comes out fine.
i.e.
15/08/2005 to 14/08/2006 exclusive -
15/08/2006 to 14/08/2008 non-exclusive - note in second excl/non excl period

Can anyone advise if this is some kind of strange setting please.

Many thanks

Paul
 
P

Peter Jamieson

I can replicate some of this here using Word 2003 and a simple .txt file as
a data source but have not yet seen the "squares" - just the disappearance
of any new lines when the field is in a table

Which version of Word are you using, what is the data source, and how are
you connecting to it?

In my tests, there are essentially three ways to connect to a .txt file in
Word 2003 - using Word's internal text converter, using an OLEDB provider,
and using ODBC. The problem did not occur at all with OLEDB or ODBC in this
case.

I don't know of a setting which would make the behaviour different, but
trying a different connection method may help if one is available (in Word
2003, check Tools|Options|General|"Confirm conversion at open" to see an
additional dialog box when you try to reconnect tot he data source).

Peter Jamieson
 
P

PaulSilverman

Peter
Many thanks for your reply. I've tried using OLE and I still get the same
behaviour. Damn!
Unfortunately, there's no easy way to post the file etc here, which I'd
probably not want to do anyway. I could send them to you if you'd be willing
to look at this further.
Answers to your questions:
- Word 2003 (11.5604.5703)
- Connecting via OLE DB Database Files or Text Files
- File is comma delimeted, first row contains headings

Any further thoughts would be most welcome!

Kind regards

Paul
Peter Jamieson said:
I can replicate some of this here using Word 2003 and a simple .txt file as
a data source but have not yet seen the "squares" - just the disappearance
of any new lines when the field is in a table

Which version of Word are you using, what is the data source, and how are
you connecting to it?

In my tests, there are essentially three ways to connect to a .txt file in
Word 2003 - using Word's internal text converter, using an OLEDB provider,
and using ODBC. The problem did not occur at all with OLEDB or ODBC in this
case.

I don't know of a setting which would make the behaviour different, but
trying a different connection method may help if one is available (in Word
2003, check Tools|Options|General|"Confirm conversion at open" to see an
additional dialog box when you try to reconnect tot he data source).

Peter Jamieson

PaulSilverman said:
Help, I am trying to merge contract information from a database.
Some "fields" contain "return" characters, or "paragraph marks" i.e.
CHR(13)
What I find is that if the field in the merge template is in a table and
has
no paragraph mark underneath it, all the "return" characters appear as
squares and the text runs together.
i.e. []15/08/2005 to 14/08/2006 exclusive - []15/08/2006 to 14/08/2008
non-exclusive - note in second excl/non excl period[]

If I add a "return" character to the end of the text, it all comes out
fine.
i.e.
15/08/2005 to 14/08/2006 exclusive -
15/08/2006 to 14/08/2008 non-exclusive - note in second excl/non excl
period

Can anyone advise if this is some kind of strange setting please.

Many thanks

Paul
 
P

Peter Jamieson

You are welcome to send them to me and I'll look a.s.a.p. - you will need to
despam my e-mail address (delete "killmapS" )

Peter Jamieson

PaulSilverman said:
Peter
Many thanks for your reply. I've tried using OLE and I still get the same
behaviour. Damn!
Unfortunately, there's no easy way to post the file etc here, which I'd
probably not want to do anyway. I could send them to you if you'd be
willing
to look at this further.
Answers to your questions:
- Word 2003 (11.5604.5703)
- Connecting via OLE DB Database Files or Text Files
- File is comma delimeted, first row contains headings

Any further thoughts would be most welcome!

Kind regards

Paul
Peter Jamieson said:
I can replicate some of this here using Word 2003 and a simple .txt file
as
a data source but have not yet seen the "squares" - just the
disappearance
of any new lines when the field is in a table

Which version of Word are you using, what is the data source, and how are
you connecting to it?

In my tests, there are essentially three ways to connect to a .txt file
in
Word 2003 - using Word's internal text converter, using an OLEDB
provider,
and using ODBC. The problem did not occur at all with OLEDB or ODBC in
this
case.

I don't know of a setting which would make the behaviour different, but
trying a different connection method may help if one is available (in
Word
2003, check Tools|Options|General|"Confirm conversion at open" to see an
additional dialog box when you try to reconnect tot he data source).

Peter Jamieson

message
Help, I am trying to merge contract information from a database.
Some "fields" contain "return" characters, or "paragraph marks" i.e.
CHR(13)
What I find is that if the field in the merge template is in a table
and
has
no paragraph mark underneath it, all the "return" characters appear as
squares and the text runs together.
i.e. []15/08/2005 to 14/08/2006 exclusive - []15/08/2006 to 14/08/2008
non-exclusive - note in second excl/non excl period[]

If I add a "return" character to the end of the text, it all comes out
fine.
i.e.
15/08/2005 to 14/08/2006 exclusive -
15/08/2006 to 14/08/2008 non-exclusive - note in second excl/non excl
period

Can anyone advise if this is some kind of strange setting please.

Many thanks

Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top