truncation of memo field supplied by DLookUp in a report

[SlowArrow]

I had a "truncation of memo field" problem, similar to the ones I could see
here, but with no solution, at least in my case. To be honest, I posted a
similar note attached to an already solved question in one Experts-Exchange
thread.

The report is based on a query, and its target (among others) to display the
whole contents of some data from a memo field (from an oracle database via
the ms odbc to oracle driver). There is a grouping inside the report, via its
Sorting & Grouping facility.

If the query contains the memo field also and the report refers that
memofield in a textfield of the detail section, than a truncation happens
after the 255th character position, even if the can grow property is set to
yes, and the memo doesn't contain carriage controls and/or line feeds. I know
about this problem, so I changed ...

.... the control source of that text field to a DLookUp(....) to obtain the
memo-data from the table directly, then .... I have the following strange
experience: OR the WHOLE contents of the memo appears in the report (on the
preview and on the paper: no difference), OR it is truncated at the end of
the first line at a word boundary. This is independent of wheather the query
contains the memo or not (however I don't use it, because I address the memo
via the control source of the report field directly, so - I believe - the
report executes the necessary groupping and sorting on the base-query
supplied data, and - just after then - obtains the necessary data from the
memo directly). However, it seems to me, that the effect is dependent of just
the contents of the memo, and NOT the placement on the screen or the paper.

I use MS Access'2003, with all the office service packs... however, there
could be some updates since the last pack, which are not installed (so, there
could be a suggestion to install some specific update, and I would be able to
test it, at least in a test environment).

I would appreciate all help

 

[Duane Hookom]

I'm trying to find a question in your posting.
DLookup() can return more than 255 characters.
A subreport could return more than 255 characters.
A control in a group header or footer will generally truncate an expression
to 255 characters.
A field in a totals query will generally be truncated to 255 characters.
A field in a standard union query (not UNION ALL) will generally truncate a
field to 255 characters.
A text box with the Format property set will truncate the display to 255
characters.

 

[SlowArrow]

Thanks for your attention I thought, it is clear from the whole story...

Just to clerify, in the last version of the program I used DLookUp to get
the memo field, which is in the detail section.

The database contains different length of texts in the memo field in the
different records, and in many cases they are much more then 255 characters.
However, in many cases the report is able to show the whole length of the
text (even if it is more then 255 characters) in more place that it was given
for the text field (the "can grow" option works), sometimes it is unable to
do it. My question: why is that? The incriminated memos (where the "can grow"
does not seem to be working) contain just normal writable characters. Or is
that all right (then: why?) ?

Thanks ahead,

(sometimes) Slow Arrow

 

[SlowArrow]

huh, the previous reply was lost somehow:-(((

Thanks for your attention

However, from your statements I can't deduct: why is able the report
generator to produce the expected result on one record, and why not on the
other. The query produces the good records, DLookUp obtains the whole
memotext on each record, but some data is disgusting for the report
generator, and it likes the other... (changing the DLookUp with a public
function of the same purposeé it results the same report, and the logs i made
support my statements).

It is just me, who see a question mark at the end of the previous paragraph?


Slow Arrow

 

[Duane Hookom]

If this occurs with some records and not with others in the same control on
the same report, then I expect the page might be rendering more quickly than
the records can be fetched. It would be interesting to find out if you
imported the Oracle records into an Access table and then used the local
table.

Is there a reason why you can't add the Oracle table to the report's record
source?
Did you try a subreport in place of the DLookup()?

 

[SlowArrow]

Thanks again, i appreciate, it was really helpful

Is there a reason why you can't add the Oracle table to the report's record

source?

At the moment, the report's record source is a query built via the designer
tool of the access (i love this graphical tool Just to know: this query is
based upon an other UNION querie (of some oracle tables) and some linked
oracle tables. But you gave me an idea: to build the query as an oracle
view... If the slowness is a problem, perhaps, this may solve it. Don't you
think?

It would be interesting to find out if you

imported the Oracle records into an Access table and then used the local
table.

Yes, this seems to be the easiest way to test, whether the speed causes the
problem...

Did you try a subreport in place of the DLookup()?

Not yet, but i will try it

The next time i may try things is tomorrow, but i will tell the results here.

Regards,

Slow Arrow (especially on weekends, without easy access to the resources

 

[Duane Hookom]

It is generally a good idea to push most of the processing to the server.

 

[SlowArrow]

Shortly and honestly: it was just my strong carelessness, which caused the
problem. The format contained a "standard" setting.

I really don't understand, because I checked it many times in the last days,
and I remember, that i cleared it... God, where is my cavinton, and where are
my glasses? ;-)

Duane, thank you very much your care! (my face is red

 

[SlowArrow]

Just to let you know: both that version where the report referred to a memo
field in the query and the other, where the report referred directly to the
memo field in the table via a DLookUp, works.