Yeah I remember using char(255) alot, I remember the conversations of the
differences between 255 and 32, hard vs soft spaces.
I just decided to go with the cursor. Here's my code in case anyone's
interested.
SET WIDTH 1500
SET NULL ' '
SET VAR vCRLF TEXT = (CHAR(13)+CHAR(10))
SET VAR vDataLine TEXT = NULL
SET VAR vDataLength INT = 1413
SET VAR vPastEnd INT = (.vDataLength+1)
SET VAR vTotalLength INT = (.vDataLength+2)
OUTPUT mib.txt
DROP CURSOR c1
DECLARE c1 CURSOR FOR SELECT policy_no, tmpuniquetext, ssn, firstname, +
middlename, lastname, suffix, dobtext8, sex, address1, address2, city, +
state, zipcode, effdatetext8, poltermtext +
FROM tmpMIB
OPEN c1
WHILE 1 = 1 THEN
FETCH c1 INTO vpolicyno, vunique, vssn, vfirst, vmiddle, vlast, vsuffix, +
vdob, vsex, vadd1, vadd2, vcity, vstate, vzip, veffdatet, vpoldatet
IF SQLCODE = 100 THEN
BREAK
ENDIF
SET VAR vDataLine = .vpolicyno
SET VAR vDataLine = (SPUT(.vDataLine, .vunique, 51))
SET VAR vDataLine = (SPUT(.vDataLine, .vssn, 101))
SET VAR vDataLine = (SPUT(.vDataLine, .vfirst, 110))
....... many more additions
--Add CarriageReturn/LineFeed charaters to the line
SET VAR vDataLine = (SPUT(.vDataLine,.vCRLF,.vPastEnd))
--Make sure no trash data exists beyond CR/LF
SET VAR vDataLine = (SGET(.vDataLine,.vTotalLength,1))
--Write the line, telling RBASE not to add its own CRLF
WRITE .vDataLine CONTINUE
ENDWHILE
DROP CURSOR c1
OUTPUT SCREEN
Karen
-----Original Message-----
From: Bruce A. Chitiea <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Tue, Jan 6, 2015 3:19 pm
Subject: [RBASE-L] - Re: Fixed field file
[Alt-255] was a real fave back in the day. I still find it working in various
Windows-based applications.
Works in Outlook.
Didn’t Microsoft introduce a different [Alt-xxx] for HdSpace in Windows 95?
Bruce
From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath
Sent: Tuesday, January 06, 2015 6:51 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Fixed field file
It is really funny how inconsistent various viewers are about interpreting LF
and CR.
LF is a linefeed which originally created a new line.
CR originally just returned the cursor to the beginning of the line.
And Microsoft (or whoever) made a major mistake in not retaining 255 as a blank
character.
From: [email protected] [mailto:[email protected]] On Behalf Of Karen Tellef
Sent: Tuesday, January 06, 2015 8:43 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Fixed field file
What do you mean, Dennis? See my response below (I'll strip all posts and just
show it). I tried just a 13, just a 10, and a 13/10. Putting a 13 in there
anywhere created a double cr
karen
-----Original Message-----
From: Dennis McGrath <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Tue, Jan 6, 2015 8:34 am
Subject: [RBASE-L] - Re: Fixed field file
How about adding a CR character at the end?
2 cR’s may not be a problem, it is the LF that makes a new line.
Dennis McGrath
Well, Albert's solution ALMOST works. It does indeed put a carriage return
exactly where I want it, so it retains the 675 blank spaces at the end.
However, it puts an extra carriage return (therefore a blank row) between each
row of data. Is there a way to suppress that, like a "write.... continue"
would? Here's the relevant code and how different "vCRLF" variables evaluated:
SET WIDTH 1500
SET VAR vCRLF = (CHAR(013))
SET HEADINGS OFF
SET SELMARGIN 1
OUTPUT MIB.TXT
SELECT ( LJS(SGET(policy_no,12,1),50) + LJS(tmpUniqueText,50) + LJS(ssn,9) +
LJS(firstname,50) +
+ ....... + (SFIL(' ',675)) + .vCRLF )=1450 +
FROM tmpMIB
OUTPUT SCREEN
Value of vCRLF:
char(013) + char(010) this puts a blank row between each data row
char(013) same as above
char(010) does not retain the blank spaces, does a carriage return right
after last data
Karen
