DAO Garbage at 256+ Characters

[David Merrick]

Hi ! can any of you help ?

Since datasheets and forms can happily display calculated fields over 255 characters long,
I was surprised to discover that the same when read via a DAO recordset beyond 255
characters is replaced with garbage.
I'd be interested in how many of you also experience this problem. To see if you have, try
one of the follow examples.

Example
----------
To display the last 60 of 300 'x's, press Ctrl-G and enter the following:

(*** TYPE AS ONE LINE ***)
?Mid(dbengine(0)(0).OpenRecordset("Select String(300,'x') From
MSysObjects").GetRows(1)(0,0),241)

If the above produced some 'x's followed by garbage, rather than entirely 'x's, then you
have the problem too.
The following clearly shows that the field calculations are actually carried out
correctly:

(*** TYPE AS ONE LINE ***)
?dbengine(0)(0).OpenRecordset("Select String(300,'x') As Str,Mid(Str,200) From
MSysObjects").GetRows(1)(1,0)

Details
--------
When an SQL calculated field exceeds 255 characters, the result is a Variable-Size Text
Field, Size 0.
The field displays fine in text boxes, datasheets and when using DLookup, but produces
garbage after the 255th character only when read programmatically with recordsets. This
garbage differs with whether you interrogate it as Recordset!Field or
Recordset!Field.Value, or RecordSet("Field") versus RecordSet!Field, or when you specify
such things as dbForwardOnly or not, etc.
Anything calculative seems to do this - functions returning over 255 characters, or just
simple equations like MemoFieldOver255Chr & 'xxx'. The calculations are performed
correctly internally, as the second example below shows.
Placing the SQL as the RecordSource of a form and using a TextBox to display the offending
field results in correct data, and then doing a Form.RecordSetClone and reading the source
data of that TextBox yields the usual garbage !!
If you Select Into a new Table you get truncation of the data to 255 chr
If you Insert Into an existing Table with the offending field a Memo, it is correctly
written
GetChunk etc fails as it thinks it is a Variable Size Text Field, Size 0
Reading through the garbage in a non-unicode loop from bytes 512 To 599 suggests no
particular rhyme or reason, as there are only a few fragmentary repeating numbers after
character 255 for a string that should be entirely repeating characters.
The *practical* problem arises particularly with generic functions carrying out actions
using recordsets (or Sql) passed as parameters, the only workaround I can see is to create
a temporary table with Memos, perform an Insert Into and read the data off, then delete
the table.

Environment
---------------
This occurs for me on Access 97, 2000 and 2002, latest service packs on both Jet and
Access.
I have XP Home edition but I asked someone on an entirely different OS, different
Access 97 and DAO service packs, and the results were the same.

I'd very much hope to hear what you folk find, and any solutions...

David

[Michael \(michka\) Kaplan [MS]]

Well, I can tell you for sure that the methods that work do not attempt to
use the DAO GetRows() method. Do you specifically need it for anything in
particular?
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"David Merrick" <de********@members.v21.co.uk> wrote in message
news:3f******@news.greennet.net...

Hi ! can any of you help ?

Since datasheets and forms can happily display calculated fields over 255 characters long, I was surprised to discover that the same when read via a DAO recordset beyond 255 characters is replaced with garbage.
I'd be interested in how many of you also experience this problem. To see if you have, try one of the follow examples.

Example
----------
To display the last 60 of 300 'x's, press Ctrl-G and enter the following:

(*** TYPE AS ONE LINE ***)
?Mid(dbengine(0)(0).OpenRecordset("Select String(300,'x') From
MSysObjects").GetRows(1)(0,0),241)

If the above produced some 'x's followed by garbage, rather than entirely 'x's, then you have the problem too.
The following clearly shows that the field calculations are actually carried out correctly:

(*** TYPE AS ONE LINE ***)
?dbengine(0)(0).OpenRecordset("Select String(300,'x') As Str,Mid(Str,200) From MSysObjects").GetRows(1)(1,0)

Details
--------
When an SQL calculated field exceeds 255 characters, the result is a Variable-Size Text Field, Size 0.
The field displays fine in text boxes, datasheets and when using DLookup, but produces garbage after the 255th character only when read programmatically with recordsets. This garbage differs with whether you interrogate it as Recordset!Field or
Recordset!Field.Value, or RecordSet("Field") versus RecordSet!Field, or when you specify such things as dbForwardOnly or not, etc.
Anything calculative seems to do this - functions returning over 255 characters, or just simple equations like MemoFieldOver255Chr & 'xxx'. The calculations are performed correctly internally, as the second example below shows.
Placing the SQL as the RecordSource of a form and using a TextBox to display the offending field results in correct data, and then doing a Form.RecordSetClone and reading the source data of that TextBox yields the usual garbage !!
If you Select Into a new Table you get truncation of the data to 255 chr
If you Insert Into an existing Table with the offending field a Memo, it is correctly written
GetChunk etc fails as it thinks it is a Variable Size Text Field, Size 0
Reading through the garbage in a non-unicode loop from bytes 512 To 599 suggests no particular rhyme or reason, as there are only a few fragmentary repeating numbers after character 255 for a string that should be entirely repeating characters.
The *practical* problem arises particularly with generic functions carrying out actions using recordsets (or Sql) passed as parameters, the only workaround I can see is to create a temporary table with Memos, perform an Insert Into and read the data off, then delete the table.

Environment
---------------
This occurs for me on Access 97, 2000 and 2002, latest service packs on both Jet and Access.
I have XP Home edition but I asked someone on an entirely different OS, different Access 97 and DAO service packs, and the results were the same.

I'd very much hope to hear what you folk find, and any solutions...

David

[David W. Fenton]

de********@members.v21.co.uk (David Merrick) wrote in
<3f******@news.greennet.net>:

This occurs for me on Access 97, 2000 and 2002, latest service
packs on both Jet and Access.
I have XP Home edition but I asked someone on an entirely
different OS, different Access 97 and DAO service packs, and the
results were the same.

I'd very much hope to hear what you folk find, and any
solutions...

I don't use GetRows, but I've encountered exactly what you're
encountering in many situations where I was concatenating memo
fields (for the printing of a catalog in Word, which needed to
concatenate multiple comment fields).

The only solution I came up with was to leave the concatenation to
the very end. If you look at the source for this (all on one line):

http://wurlitzerbruck.com/Search/ind...ss=search&List[]=Aut
ograph+Letters%2C+signed&show_body=1

You'll see multiple spaces in some of the comments. This is because
three comment fields are being concatenated in the PHP code. Since
HTML handles redundant spaces properly, it works OK (i.e., in HTML
2 spaces or 3 or 10 are rendered as 1), so this works out OK.

In non-HTML contexts, it's more complex.

Displaying the same data in a Word merge file, I have to test the
individual fields to figure out where to put a space, and the
conditionals get pretty messy looking.

I posted about this problem along time ago and got no real answers
on it -- it seems that few people have encountered this problem.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[deemerrick]

Hello ! thanks for the two postings.

The .GetRows() was purely to make the example simple to paste in.

You'll see from the message the other ways the problem arises : in
general, every way of reading the data through DAO exhibits the problem
of fields over 255 characters long being garbaged, of which reading
Recordset!Field values will be the most common structure affected.

I've subsequently tried it on more environments, and it does seem to
affect all versions of DAO (try referencing different versions), Access,
and Windows.

I was unable to tell exactly from the source html of your link what you
were really meaning as a workaround for generic functions. With specific
functions, you can read the raw field data yourself and code the desired
equations in your language code outside the Sql. However, if Sql is
passed to a generic user-defined function, the function doesn't want to
have to be told how to concatenate fields together itself explicity in
code, it should all be done in the Sql or Recordset that is passed in.
Also, since many calculated fields do not involve simple concatenation
(e.g. it might involve using the result of a user-defined- or build-in-
function which returns a string more than 255 characters, as in the
example), this makes it impossible to write generic functions handling
Recordsets through the simple workaround of passing in a parameter which
tells the generic function which fields to aggregate together. The only
two workarounds I can see is that the function should detect a certain
field name suffix which indicates to Eval that field value (having first
replaced values inside it with the other fields) e.g. Select
'MyFunc({Age},{Name})' As FnEval, ... would cause it to be replaced with
values read from other fields e.g. MyFunc(23,'Michael') and then be Eval()-
ed, e.g. 'Michael is 23'.

The second method is to create a temporary table and do an Insert Into
and then open that temporary table. This would work for Sql passed in,
but not Recordsets.

Thanks,

david
--
Posted via http://dbforums.com