Hello all:

I need to create an ASCII export (using AREV's export utility) with 13,10 (CRLF) as the field delimiter; this works fine for a record delimiter, but as a field delimiter the numbers 13,10 become embedded in the data. Any suggestions?

TIA,

Mike O.

Mike,

This is a long shot. If you have REV G, there is a Utility called PORTER that you could copy into AREV and edit the delimiters. Then use PORTER to export the data. I wish that it was possible to edit the export routine in AREV. If any out there knows how, I too would appreciate it.

Dale Walker

[email protected]

I'm afraid that unless you write your own export routine, you'll have some problems. The MS-DOS record delimiter is 13/10 and this is what the export program will append to the end of the record. Unless you write a pile of symbolics that also append 13/10 to the field data for each element you might need and then these are the ones you output, I don't see any good work-around. AREV doesn't allow 13/10 as a record delimiter in the standard output specification for variable-length data. It might be easier to write your own export if you're comfortable with OSBWRITE, etc. since you can create your output stream any way you want.

Don Miller

C3 Inc.

I seem to recall that the source code to several Revsoft? export routines for AREV was floating around somewhere .. maybe in the recent Sprezz utility series released on their site. The problem is compounded because the export definition doesn't allow for this. You might have to use some other "strange" delimiter and then do a SWAP in the export program. This probably beats writing a lot of symbolics, though.

Don Miller

C3 Inc.

The source code for the import & export programs have been shipping with ARev since version 2.1.

Included in the disks should be a REVSRC.EXE (self-extracting archive, revmedia file include). Extract the files to a directory, attach the volume and look in REVSOURCE.

Note: there is a Y2K problem in the DBase export program versions prior to 3.1x. Dates are constructed taking only 2 digits for the year in these versions.

Hello everyone:

Thanks for all the input - especially the G2 PORTER suggestion, hadn't thought of that in *years*!

Mike O.

Perhaps one of the easiest methods is to generate the code needed and modify it accordingly.

Run a TCL LIST statement with options (SX) to produce the source code in a DOS file called RLIST, then edit RLIST to suit.

Clarification on DBase export Y2K problem: versions prior to 3.1x construct the internal DBase date always with the assumption that the first two digits are 19.

For a comprehensive export utility that will handle tthis and other formatting problems, check my free Export utility at:

http://www.ts.co.nz/~finsol

Regards

Jocelyn Amon

View this thread on the forum...