select mline returns truncated values
- From: "Matthew L Reed" <nousenetspam at dead ice dot us>
- Date: Tue, 25 Oct 2005 09:38:28 -0700
This is an issue I remember from years ago, but don't remember the solution.
Do this:
CREATE CURSOR zoot (zz m, SelectMe L)
INSERT INTO zoot (zz, SelectMe) VALUES ('aa' + CHR(13) + 'bb' + CHR(13) +
'cc', .F.)
INSERT INTO zoot (zz, SelectMe) VALUES ('aa' + CHR(13) + 'bbbbb' + CHR(13) +
'cccccccccc', .T. )
INSERT INTO zoot (zz, SelectMe) VALUES ('aa' + CHR(13) + 'bbbbb' + CHR(13) +
'cccccccccc', .T. )
INSERT INTO zoot (zz, SelectMe) VALUES ('aa' + CHR(13) + 'bbbbb' + CHR(13) +
'cccccccccc', .T. )
SELECT MLINE(zz,2) FROM zoot WHERE SelectMe
Look at your output. Notice that the data is truncated and instead of
'bbbbb', we only get 'bb'. Look at the structure of your cursor. It is
c(2). This is what VFP does - it evaluates the first record in the table and
uses that to determine the width of the field in your output cursor,
regardless of whether or not this record is actually included in the result
set. The filter on SelectMe proves this, as the first record is not included
in the output set, yet VFP still evaluates it with the MLINE function from
the SELECT statement. In this case, the first record returns 'bb', so the
query engine assumes that we want an output structure with c(2). This causes
truncation of any data that exceeds c(2) in other fields.
I hesitate to call this a bug, as Fox has always done this. It's more of a
stupid feature by design.
Question - how to work around this?
.
- Follow-Ups:
- Re: select mline returns truncated values
- From: Anders
- Re: select mline returns truncated values
- From: Dan Freeman
- Re: select mline returns truncated values
- Prev by Date: Re: Skipping instruction line when returning from call to Word.
- Next by Date: Re: ODBC vs FoxPro matching
- Previous by thread: RE: patched FPW 2.6 divide by zero error.
- Next by thread: Re: select mline returns truncated values
- Index(es):
Relevant Pages
|