I've just read about AREV 3.12's Import/Export processes yesterday. My initial testing with the variable length ASCII process looks like what we want for moving data to and from SQL files. So far my testing has only found one problem. The only problem I've found so far is with a single row and a single column that contains text data. I'm betting that if there is one problem like this then there may be more.

I've setup my export and import processes for ASCII, variable length using the char(157) (the YEN symbol) as the field delimiter, carriage return line feed as the end of row and CTRL_Z as end of file.

I exported one table to the ASCII file, cleared the AREV table then imported the just created ASCII file back into the original AREV table. In checking my results, I found one column within one row that contained the original data plus the rest of the ASCII record that came after it within the exporeted ASCII file. The extra data was the field delimiters that I had defined and any data that was between them. The original text within the column read "24 DV'S" (without the double quotes). I then cleared the table again. Edited the ASCII table by removing the single quote from the problem field and saved the ASCII file. So no the text reads "24 DVS". Then I imported the ASCII file just like before. This time everhting was in its proper place and all was right with the world. So the single quote with the text column seems to be the culprit.

In my reading of the manual and the help information behind each of the prompts for the Import and Export windows, I saw something that mentioned being able to put double quotes (or the like) around the fields within an ASCII file so any characters that might otherwise be missunderstood as a delimiter won't be. For the life of me I can't seem to find were that is mentioned again. Can anyone tell me were I need to look for that information?

Does anyone have any words of wisdom or warning about the Import/Export process and transfering data back and forth between AREV and SQL? What is the best approach that you have found for doing that?

Thank You,

Michael Slack

I've given up exporting data from ARev using the built-in process. It's simpler and more flexible to run a subroutine to perform the export for you.

Subroutine Exporter

*

DECLARE SUBROUTINE FSMSG

*

OPEN "YOURFILE" TO ACTIVE_FILE$ ELSE FSMSG() ; STOP

OPEN "DICT","YOURFILE" TO @DICT ELSE FSMSG() ; STOP

EOF=0

PERFORM "PDISK EXPORT.DAT"

PRINTER ON

SELECT ACTIVE_FILE$ ; * or run PERFORM "SELECT YOURFILE WITH XYZ GE 1200"

*

LOOP

READNEXT @ID ELSE EOF=1

WHILE EOF=1

READ @RECORD FROM ACTIVE_FILE$ THEN

  OUTRECORD="'  ; * single quote, double quote, single quote

  OUTRECORD := {ITEM_ONE} : '","' ; * single double comma double single

• * continue adding fields in same way, with delimite

  OUTRECORD := {LAST_ITEM} : '"'  ; * row ends with single double single

  PRINT OUTRECORD

REPEAT

PRINTER OFF

PERFORM "PDISK PRN"

RETURN

This routine sends everything as if printed to the .DAT file. Just be sure to turn the printer off before exiting, and to return control to the printer using PDISK.

Mike, this looks an awful lot like what I do with many of my programs that are built for importing into EXCEL.

View this thread on the forum...