Re: Lengthy merge code
- From: "Peter Jamieson" <pjj@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 24 Jan 2007 17:52:41 -0000
The only type of code that does anything like that is a { SKIPIF } code and
as far as I can tell that's not appropriate for your situation - i.e. it's
there to stop processing of the current record altogether when the condition
specified in the SKIP is found.
Not much helps when you're dealing with large numbers - you can't convert
your data to Access, for example, because it has a 255-column maximum, and
that's why you probably wouldn't be able to use SQL even if you wanted to.
The merge takes a long time, and I assume it's because word is ticking
through each line of code and saying to itself 'yes/no.'
It could well be that. It could also be because Word takes quite a long time
even to read a long text record and split it up into separate fields. (It
shouldn't but as far as I can tell, it does). Doing lots of INCLUDETEXTS is
likely to have a significant impact as well. There are some unuaul
text/formatting features that can slow processing down (e.g. "formatted
bullets"), but I think you would be able to tell if you have any of those by
taking out most of your fields and seeing if the merge is still slow. You
may also find that Word gets progressively slower as it works its way
through your data file, and if that is the case, it /might/ make sense to do
the merge in multiple chunks.
However, in my view, this is a classic case of "if it ain't broke, don't
'fix' it": if I had the option, I'd probably just want to check that
increased memory or processor speed made a difference, but that's about it.
Peter Jamieson
"Heather" <heather.c@xxxxxxxxx> wrote in message
news:1169659711.224146.230590@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi, all - I have a question that's probably painfully easy and obvious,
but I'm stumped.
I'm working with a very large (1400+ columns) csv file to create
customized letters for our students. I used merge code to determine
scholarships and special program offers based on things like admission
averages. Unfortunately, an admission average can appear in one of ten
positions, and within the one in ten, in one of six positions. So,
naturally, my merge code is long. I don't know sql and there isn't time
to write new programming, so I'm stuck with my pages and pages of merge
code.
To try to improve performance, I have code stored in different
files...so with the main letter, if the individual record meets certain
criteria, there's an includetext function for a document. That
document, in turn, has includetext functions from a master document
that inserts appropriate paragraphs. It works - it's not pretty, but it
works.
The merge takes a long time, and I assume it's because word is ticking
through each line of code and saying to itself 'yes/no.'
My question is: is there something I can insert into my code to say
that if the condition is found (positive result), to stop searching
though the rest of the code in that linked document and move on?
Thank you again for your help. This group has been an invaluable
resource.
Heather
.
- Follow-Ups:
- Re: Lengthy merge code
- From: Heather
- Re: Lengthy merge code
- References:
- Lengthy merge code
- From: Heather
- Lengthy merge code
- Prev by Date: Lengthy merge code
- Next by Date: Re: Lengthy merge code
- Previous by thread: Lengthy merge code
- Next by thread: Re: Lengthy merge code
- Index(es):