Home > Archive > Clipper > March 2005 > Re: conversion of file from one format to other
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: conversion of file from one format to other
|
|
| rajeev chavan 2005-03-22, 3:55 pm |
| Hi Everbody
Thanks for your response.
To E.Fridman :
The program which converts from its native file format to ASCII is not
converting the records at 1 record per line.It breaks (with CRLF) the record
at 2-3 places.The record starts at date.So from one date to next date is one
record.Generally one record spans 3 lines(and 2 CRLFs) but not always eg
check 4th record.
To Lee Clinkscales :
Your idea of having date field as character is great.Otherwise I was getting
date as blank.What do you mean by "expanded dbf"
To Pete :
You have also mentioned about keeping date as character.Thanks for advice.As
I have explained above each record is getting broken at 2-3 places so simple
APPEND FROM wont work.
To Ross :
Many many thanks for the program.Although the format in which my program
requires XML file is little different I will try to improve upon your
program.I will come back to you if I find any dificulty.Thanks once again.
To All :
I need to process the ASCII file so that I have 1 record per line as
follows(pls view the follo with window maximized)
1-3-2005,"RETREADING RECEIPTS (CASH)","Sale",-5000.00,,"Ch. No. :qweq","(No.
:8830/SR)",
1-3-2005,"DABHT (ABHISKEH TRANSPORT)","Rcpt",-2000.00,,"C","(No. :1)",
1-3-2005,"RETREADING RECEIPTS (CASH)","Sale",-8000.00,,"(No. :8837/SR)",
2-3-2005,"RETREADING RECEIPTS (CASH)","Sale",-6000.00,,"Ch.
No. qw345v45y5275745745747547477487878744757
7547475477437tuiytieitueitueiutie
uieutieutiuiu583539938383938938535383583
83838538538538538583uuuuiuriewuitier
giggiriutiutiutiwtuu55729529485238583582
339885dkuut09912lowetysgerl","(No.
:8841/SR)",
2-3-2005,"CMRFL (MRF LTD)","Pymt",,5000.00,"Ch. No. :123456 pd for
purchases","(No. :1)",
Pls advice.
TIA
Rajeev Chavan
"E. Fridman" <pm771.am@gmail.com> wrote in message
news:1111426720.742726.197240@l41g2000cwc.googlegroups.com...
> Re: ASCII to DBF.
>
> It is not clear from your post where do you have [CR] and/or [LF]
> characters in your ASCII file.
>
| |
| gabor salai 2005-03-22, 3:55 pm |
| "rajeev chavan" <sschavan_REMOVE_ME_@eth.net> wrote in message
news:3aakqnF66s6g9U1@individual.net...
> I need to process the ASCII file so that I have 1 record per line as
> follows(pls view the follo with window maximized)
>
> 1-3-2005,"RETREADING RECEIPTS (CASH)","Sale",-5000.00,,"Ch. No.
:qweq","(No.
> :8830/SR)",
> 1-3-2005,"DABHT (ABHISKEH TRANSPORT)","Rcpt",-
may you verify that from date-to-date you have *constant*
characters length. if so, it would be simple to extract cr/lf
your conversion program inserted, and restore lines counting
chars from file begining.
otherwise, you need [simple] program to read ascii file, skip cr/lf
and parse lines [inserting new cr/lf], syncing on first date expresion,
in form of "mn-mn-nnnn".
| |
| Stephen Quinn 2005-03-22, 8:55 pm |
| Rajeev
> converting the records at 1 record per line.It breaks (with CRLF) the record
> at 2-3 places.The record starts at date.So from one date to next date is one
Are you sure about the 2-3 CRLFs??
Have you looked at the file with a hex editor to verify??
It may be the editor your using to look at the file that is causing the line to
wrap 2-3 times or maybe the memo data has CRLFs embedded in it.
I wouldn't expect export to CSV file to embed CRLFs in the record, only at EOL.
--
HTH
Steve
| |
| pete@nospam.demon.co.uk 2005-03-23, 8:55 am |
| In article <3abkc1F6af0voU1@individual.net>
steveqNOSPAM@integritynet.com.au "Stephen Quinn" writes:
> Rajeev
>
> Are you sure about the 2-3 CRLFs??
> Have you looked at the file with a hex editor to verify??
>
> It may be the editor your using to look at the file that is causing the line to
> wrap 2-3 times or maybe the memo data has CRLFs embedded in it.
Or even the application that is creating this file (what is it?).
Looking closer at your original posting it does not even seem to
be creating the same number of fields per "line" (not to mention
the trailing commas). I've split your original into "fields" as
below:
1 1-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -5000.00,
5 ,
6 "Ch. No. :qweq",
7 "(No. :8830/SR)",
1 1-3-2005,
2 "DABHT (ABHISKEH TRANSPORT)",
3 "Rcpt",
4 -2000.00,
5 ,
6 "C",
7 "(No. :1)",
1 1-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -8000.00,
5 ,
6 "(No. :8837/SR)",
1 2-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -6000.00,
5 ,
6 "Ch. No. :qw345[..snip..]lowetysgerl",
7 "(No. :8841/SR)",
1 2-3-2005,
2 "CMRFL (MRF LTD)",
3 "Pymt",
4 ,
5 5000.00,
6 "Ch. No. :123456 pd for purchases",
7 "(No. :1)",
As you can see, the 3rd "record" has only 6 commas where all the
others have 7 -- data like this will be a nightmare to parse.
> I wouldn't expect export to CSV file to embed CRLFs in the record, only at EOL.
Indeed. And vice versa: no comma at EOL (unless of course there
is an empty field there).
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
| |
| rajeev chavan 2005-03-23, 3:55 pm |
| Hi Everybody
To Gabor Salai :
Thanks for suggestion.From date-to-date the characters are not of same
length.Your other suggestion could be only way out.Although it would be
dificult to program.
To Stephen Quinn:
Yes I am sure about 2-3 CRLFs.After you expressed doubt I checked in hex
editor.It does show so.
There are no memo data.
Eventhough you may not expect CRLFs in between records,the program which
produced the file said it would create a "ASCII(delimited with comma)" file.
To Pete :
The application which is creating this file is an account program.I do not
know which language it is wrtitten in.
Your observation regarding no of fields not being fixed is very correct.The
missing field in 4th record is "Narration" which I had not entered in the
account program.Ideally there should have been comma just like for
debit/credit fields which are blank.The account program has not produced any
comma for blank character field.
Pls advice
TIA
Rajeev Chavan
<pete@nospam.demon.co.uk> wrote in message
news:1111567666snz@nospam.demon.co.uk...
> In article <3abkc1F6af0voU1@individual.net>
> steveqNOSPAM@integritynet.com.au "Stephen Quinn" writes:
>
record[color=darkred]
is one[color=darkred]
line to[color=darkred]
>
> Or even the application that is creating this file (what is it?).
> Looking closer at your original posting it does not even seem to
> be creating the same number of fields per "line" (not to mention
> the trailing commas). I've split your original into "fields" as
> below:
>
> 1 1-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -5000.00,
> 5 ,
> 6 "Ch. No. :qweq",
> 7 "(No. :8830/SR)",
>
> 1 1-3-2005,
> 2 "DABHT (ABHISKEH TRANSPORT)",
> 3 "Rcpt",
> 4 -2000.00,
> 5 ,
> 6 "C",
> 7 "(No. :1)",
>
> 1 1-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -8000.00,
> 5 ,
> 6 "(No. :8837/SR)",
>
> 1 2-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -6000.00,
> 5 ,
> 6 "Ch. No. :qw345[..snip..]lowetysgerl",
> 7 "(No. :8841/SR)",
>
> 1 2-3-2005,
> 2 "CMRFL (MRF LTD)",
> 3 "Pymt",
> 4 ,
> 5 5000.00,
> 6 "Ch. No. :123456 pd for purchases",
> 7 "(No. :1)",
>
> As you can see, the 3rd "record" has only 6 commas where all the
> others have 7 -- data like this will be a nightmare to parse.
>
at EOL.[color=darkred]
>
> Indeed. And vice versa: no comma at EOL (unless of course there
> is an empty field there).
>
> Pete
> --
> "We have not inherited the earth from our ancestors,
> we have borrowed it from our descendants."
| |
| gabor salai 2005-03-23, 3:55 pm |
| "rajeev chavan" <sschavan_REMOVE_ME_@eth.net> wrote in message
news:3adc11F69k9nkU1@individual.net...
> Hi Everybody
> To Gabor Salai :
> Thanks for suggestion.From date-to-date the characters are not of same
> length.Your other suggestion could be only way out.Although it would be
> dificult to program.
well, not so hard as to retyping data manualy into export
[other] database.
regarding missing fields [for empty character field], good point
is that you may precisely recover 1st, 4th and 5th fields [date/numeric].
but, character fields 2nd/3rd and 6th/7th pairs, only if they are
both present.
but, if one of them is missing, without further analysis
[allowed content of field, or length test], you may not know which
one is missing [event then, it is just guessing].
| |
| pete@nospam.demon.co.uk 2005-03-28, 3:55 pm |
| In article <3abkc1F6af0voU1@individual.net>
steveqNOSPAM@integritynet.com.au "Stephen Quinn" writes:
> Rajeev
>
> Are you sure about the 2-3 CRLFs??
> Have you looked at the file with a hex editor to verify??
>
> It may be the editor your using to look at the file that is causing the line to
> wrap 2-3 times or maybe the memo data has CRLFs embedded in it.
Or even the application that is creating this file (what is it?).
Looking closer at your original posting it does not even seem to
be creating the same number of fields per "line" (not to mention
the trailing commas). I've split your original into "fields" as
below:
1 1-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -5000.00,
5 ,
6 "Ch. No. :qweq",
7 "(No. :8830/SR)",
1 1-3-2005,
2 "DABHT (ABHISKEH TRANSPORT)",
3 "Rcpt",
4 -2000.00,
5 ,
6 "C",
7 "(No. :1)",
1 1-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -8000.00,
5 ,
6 "(No. :8837/SR)",
1 2-3-2005,
2 "RETREADING RECEIPTS (CASH)",
3 "Sale",
4 -6000.00,
5 ,
6 "Ch. No. :qw345[..snip..]lowetysgerl",
7 "(No. :8841/SR)",
1 2-3-2005,
2 "CMRFL (MRF LTD)",
3 "Pymt",
4 ,
5 5000.00,
6 "Ch. No. :123456 pd for purchases",
7 "(No. :1)",
As you can see, the 3rd "record" has only 6 commas where all the
others have 7 -- data like this will be a nightmare to parse.
> I wouldn't expect export to CSV file to embed CRLFs in the record, only at EOL.
Indeed. And vice versa: no comma at EOL (unless of course there
is an empty field there).
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
| |
| rajeev chavan 2005-03-30, 8:55 am |
| Hi Everybody
To Gabor Salai :
Thanks for suggestion.From date-to-date the characters are not of same
length.Your other suggestion could be only way out.Although it would be
dificult to program.
To Stephen Quinn:
Yes I am sure about 2-3 CRLFs.After you expressed doubt I checked in hex
editor.It does show so.
There are no memo data.
Eventhough you may not expect CRLFs in between records,the program which
produced the file said it would create a "ASCII(delimited with comma)" file.
To Pete :
The application which is creating this file is an account program.I do not
know which language it is wrtitten in.
Your observation regarding no of fields not being fixed is very correct.The
missing field in 4th record is "Narration" which I had not entered in the
account program.Ideally there should have been comma just like for
debit/credit fields which are blank.The account program has not produced any
comma for blank character field.
Pls advice
TIA
Rajeev Chavan
<pete@nospam.demon.co.uk> wrote in message
news:1111567666snz@nospam.demon.co.uk...
> In article <3abkc1F6af0voU1@individual.net>
> steveqNOSPAM@integritynet.com.au "Stephen Quinn" writes:
>
record[color=darkred]
is one[color=darkred]
line to[color=darkred]
>
> Or even the application that is creating this file (what is it?).
> Looking closer at your original posting it does not even seem to
> be creating the same number of fields per "line" (not to mention
> the trailing commas). I've split your original into "fields" as
> below:
>
> 1 1-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -5000.00,
> 5 ,
> 6 "Ch. No. :qweq",
> 7 "(No. :8830/SR)",
>
> 1 1-3-2005,
> 2 "DABHT (ABHISKEH TRANSPORT)",
> 3 "Rcpt",
> 4 -2000.00,
> 5 ,
> 6 "C",
> 7 "(No. :1)",
>
> 1 1-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -8000.00,
> 5 ,
> 6 "(No. :8837/SR)",
>
> 1 2-3-2005,
> 2 "RETREADING RECEIPTS (CASH)",
> 3 "Sale",
> 4 -6000.00,
> 5 ,
> 6 "Ch. No. :qw345[..snip..]lowetysgerl",
> 7 "(No. :8841/SR)",
>
> 1 2-3-2005,
> 2 "CMRFL (MRF LTD)",
> 3 "Pymt",
> 4 ,
> 5 5000.00,
> 6 "Ch. No. :123456 pd for purchases",
> 7 "(No. :1)",
>
> As you can see, the 3rd "record" has only 6 commas where all the
> others have 7 -- data like this will be a nightmare to parse.
>
at EOL.[color=darkred]
>
> Indeed. And vice versa: no comma at EOL (unless of course there
> is an empty field there).
>
> Pete
> --
> "We have not inherited the earth from our ancestors,
> we have borrowed it from our descendants."
| |
| gabor salai 2005-03-30, 8:55 am |
| "rajeev chavan" <sschavan_REMOVE_ME_@eth.net> wrote in message
news:3adc11F69k9nkU1@individual.net...
> Hi Everybody
> To Gabor Salai :
> Thanks for suggestion.From date-to-date the characters are not of same
> length.Your other suggestion could be only way out.Although it would be
> dificult to program.
well, not so hard as to retyping data manualy into export
[other] database.
regarding missing fields [for empty character field], good point
is that you may precisely recover 1st, 4th and 5th fields [date/numeric].
but, character fields 2nd/3rd and 6th/7th pairs, only if they are
both present.
but, if one of them is missing, without further analysis
[allowed content of field, or length test], you may not know which
one is missing [event then, it is just guessing].
| |
| rajeev chavan 2005-03-30, 8:55 am |
| Hi Gabor
Thanks for the suggestion.I will definitely try it out.
With Best Wishes
Rajeev Chavan
"gabor salai" <gaborDOTsalai@euroherc.hr> wrote in message
news:d1ruug$97r$1@ls219.htnet.hr...
> "rajeev chavan" <sschavan_REMOVE_ME_@eth.net> wrote in message
> news:3adc11F69k9nkU1@individual.net...
>
> well, not so hard as to retyping data manualy into export
> [other] database.
>
> regarding missing fields [for empty character field], good point
> is that you may precisely recover 1st, 4th and 5th fields [date/numeric].
> but, character fields 2nd/3rd and 6th/7th pairs, only if they are
> both present.
> but, if one of them is missing, without further analysis
> [allowed content of field, or length test], you may not know which
> one is missing [event then, it is just guessing].
>
>
>
>
|
|
|
|
|