File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP 
Author Message
 File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

I'm trying to import some data that is currently in freeform ascii or pseudo
.csv by transforming it into a .csv file first as an intermediate form.
I wonder if anyone with experience in converting spreadsheet & .csv type files
could help?
My current approach is as follows:
read in first line of ascii file (future maybe be binary or prn),
scan line for delimiters
convert line into discrete fields and store in a 2d array?
process fields as necessary.
rebuild delimited line (.csv) by concatenating fields and delimiters.
write line.
repeat

I don't have any proficiency in awk or sed, and therefore a bit
limited. I wonder if someone has done this before, and as such I would really
appreciate any assistance on being pointed to any similar source code that
I could learn and build upon.  Advice on my approach would also be appreciated.
I've searched SIMTEL20 and CUG library and could not find anything suitable that
I could modify.

Thanks
Josh

--



Wed, 18 Jun 1997 14:44:00 GMT  
 File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

Quote:
> My current approach is as follows:

    Your current approach seems like it will work. If possible, you
    may want to look at breaking up each input line "in-place", so you
    build an array of field pointers into the line rather than copying
    data into a seperate 2D array.

Quote:
> Josh

--

***  "Radioactivity - It's in the air, for you and for me" - Kraftwerk  ***


Wed, 18 Jun 1997 21:20:24 GMT  
 File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

Quote:


>  (Josh):

> > My current approach is as follows:

>     Your current approach seems like it will work. If possible, you
>     may want to look at breaking up each input line "in-place", so you
>     build an array of field pointers into the line rather than copying
>     data into a seperate 2D array.

> > Josh
> --

> ***  "Radioactivity - It's in the air, for you and for me" - Kraftwerk  ***

Thanks for the tip, I was thinking of doing the same, but got stumped when I
realised that some fields need to be stored and or incremented, while others
can go straight through. In brief, depending on what flags are present,
shorthand entries need to be unrolled, on occasion. I may also have to
modify the code frequently. I can't quite seem to figure out why I can't
malloc() a buffer of size greater than 60K. (I'm using a PC to do this, VisC,
windows 3.1 to create MS-DOS apps).
are there any not-too-difficult ways round this?
Also, I'm writing functions with the policy of always using the return
keyword for returning true or false, and passing pointers in arguments and using
strcpy() to copy back the results of string operation to the caller.
I have the feeling that I'm doing more processing than necessary but I'd like the
functions I write to be portable, at least to Unix.
Am I on the right track, can anyone advise?

thanks

Josh
--



Fri, 20 Jun 1997 16:22:40 GMT  
 File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

Quote:
> can go straight through. In brief, depending on what flags are present,
> shorthand entries need to be unrolled, on occasion. I may also have to
> modify the code frequently. I can't quite seem to figure out why I can't

    It depends on what exactly the content of these free format lines
    is, but...

    o   If the data does have some structure, then breaking it up into
        the pieces that you are interested in is a good idea. Even if
        the pieces need further processing, it's often easier to get
        them all seperated first, and then process away.

    o   Sometimes you can use a second file as a sort of description
        of what the first file is supposed to contain. Then instead of
        changing code, you can change the second file.

Quote:
> malloc() a buffer of size greater than 60K. (I'm using a PC to do this, VisC,
> windows 3.1 to create MS-DOS apps).
> are there any not-too-difficult ways round this?

    This may get a better answer in one of the PC newsgroups, but I
    haven't found any. Even in Windows, where one can allocate a chunk
    larger than 64KB with the OS, the Microsoft library functions
    don't seem to want to cross segment boundaries. So if you try and
    get the length of a string that sits astride the 64KB mark, the
    thing breaks (I encountered this with MSVC 1.5).

Quote:
> Also, I'm writing functions with the policy of always using the return
> keyword for returning true or false, and passing pointers in arguments and using
> strcpy() to copy back the results of string operation to the caller.
> I have the feeling that I'm doing more processing than necessary but I'd like the
> functions I write to be portable, at least to Unix.

    I don't think this aids portability, though you may find it helps
    how you think about your code, and may be a more defensive style
    for you. Note that you can use a pointer value of NULL to indicate
    failure from a function that should return a pointer, like fopen()
    does.

    I think it's mostly a style thing, though overuse of strcpy() is
    definitely inefficient. Some people are uncomfortable with passing
    pointers to variables to modify them, because of how they think
    about indirection.

Quote:
> Josh

--

***  "Radioactivity - It's in the air, for you and for me" - Kraftwerk  ***


Fri, 20 Jun 1997 21:53:47 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. <<<<<<<Parsing help, please>>>>>>>>

2. <<<>>>Need C code advice with functions and sorting.<<<>>>

3. <><><>HELP<><><> PCMCIA Motorola Montana 33.6

4. >>>Windows Service<<<

5. proposal: <basic.h>, <pascal.h>, <fortran.h>, <cobol.h>

6. <<<< C Grammar for yacc needed >>>>

7. - - - = = =<><> W e b - U S A <><>= = = - - -

8. >>>> * Get keypress * <<<<

9. <Ctrl>+<Key>

10. <<testing>>

11. >>I need help!<<(duh)

12. >>ATTN: SPRITEWORKS v1.0<<

 

 
Powered by phpBB® Forum Software