Prev: reading complex data using implied do loops
Next: FTP libraries
From: glen herrmannsfeldt on 3 Feb 2010 01:54
dpb <none(a)non.net> wrote:
(snip)

>> I am surprised nobobdy else seems to have faced this problem.

> What database/what client? I've not done enough true database engine
> work in 40 years to have ever run into much of any problem with one;
> when I did have needs in the area I farmed that portion out religiously.

> But, either the data are embedded w/ the LF pairs and the export
> function is simply echoing them or it's broke or configured for short
> lines that are wrapping or somesuch.

As far as I know, it would be usual when representing database
records in XML to use XML elements as record indicators, and
not CRLF, CR, or LF. That is, at least, how it was done when
I was working with XML.

> W/O more of the rest of the puzzle don't think there's anything else
> that can be said other than it isn't a Fortran problem; it's the data
> file itself that's your problem. How to fix that the way you want I've
> no clue, specifically.

-- glen
From: analyst41 on 3 Feb 2010 04:56
On Feb 3, 1:54 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> dpb <n...(a)non.net> wrote:
>
> (snip)
>
> >> I am surprised nobobdy else seems to have faced this problem.
> > What database/what client?  I've not done enough true database engine
> > work in 40 years to have ever run into much of any problem with one;
> > when I did have needs in the area I farmed that portion out religiously..
> > But, either the data are embedded w/ the LF pairs and the export
> > function is simply echoing them or it's broke or configured for short
> > lines that are wrapping or somesuch.
>
> As far as I know, it would be usual when representing database
> records in XML to use XML elements as record indicators, and
> not CRLF, CR, or LF.  That is, at least, how it was done when
> I was working with XML.
>
> > W/O more of the rest of the puzzle don't think there's anything else
> > that can be said other than it isn't a Fortran problem; it's the data
> > file itself that's your problem.  How to fix that the way you want I've
> > no clue, specifically.
>
> -- glen

It is not a Fortran problem but I'd like to solve it with fortran. I
have already come up with the workaround I posted at the start of the
thread, but that looks somewhat shaky - although it did reassemble
close to a million rows correctly.

These "spurious" EORs will be between two commas (and I know many
delimiting commas to expect per row). If there is a way to read one
byte at at time (without recognizing EORs) then I can programmatically
assemble database rows.
From: dpb on 3 Feb 2010 08:38
analyst41(a)hotmail.com wrote:
....

> These "spurious" EORs will be between two commas (and I know many
> delimiting commas to expect per row). If there is a way to read one
> byte at at time (without recognizing EORs) then I can programmatically
> assemble database rows.

I showed you the basics several posts back -- it's in F2003 as "stream"
but there's a vendor extension in virtually all compilers.

But, I'd wonder why not attack the database problem. As someone else
said, it seems quite strange to have this kind of data in a database to
begin with, at least w/ the headers.

--
From: robin on 8 Feb 2010 20:56
<analyst41(a)hotmail.com> wrote in message news:7b2461f2-efd4-4dad-8d47-42bb52d22b60(a)u26g2000yqm.googlegroups.com...

>These "spurious" EORs will be between two commas (and I know many
>delimiting commas to expect per row). If there is a way to read one
>byte at at time (without recognizing EORs) then I can programmatically
>assemble database rows.

Have you tried to read the file as a direct file, one byte at a time?


From: Jerry DeLisle on 8 Feb 2010 23:08
On 02/03/2010 01:56 AM, analyst41(a)hotmail.com wrote:
> On Feb 3, 1:54 am, glen herrmannsfeldt<g...(a)ugcs.caltech.edu> wrote:
>> dpb<n...(a)non.net> wrote:
>>
>> (snip)
>>
>>>> I am surprised nobobdy else seems to have faced this problem.
>>> What database/what client? I've not done enough true database engine
>>> work in 40 years to have ever run into much of any problem with one;
>>> when I did have needs in the area I farmed that portion out religiously.
>>> But, either the data are embedded w/ the LF pairs and the export
>>> function is simply echoing them or it's broke or configured for short
>>> lines that are wrapping or somesuch.
>>
>> As far as I know, it would be usual when representing database
>> records in XML to use XML elements as record indicators, and
>> not CRLF, CR, or LF. That is, at least, how it was done when
>> I was working with XML.
>>
>>> W/O more of the rest of the puzzle don't think there's anything else
>>> that can be said other than it isn't a Fortran problem; it's the data
>>> file itself that's your problem. How to fix that the way you want I've
>>> no clue, specifically.
>>
>> -- glen
>
> It is not a Fortran problem but I'd like to solve it with fortran. I
> have already come up with the workaround I posted at the start of the
> thread, but that looks somewhat shaky - although it did reassemble
> close to a million rows correctly.
>
> These "spurious" EORs will be between two commas (and I know many
> delimiting commas to expect per row). If there is a way to read one
> byte at at time (without recognizing EORs) then I can programmatically
> assemble database rows.

Use STREAM I/O if supported. You can read any number of characters you wish.
The following example will read one character at a time. Put the read in a loop
and the programatically do your thing.

character(1) :: char

open (unit,file="filename" , access="STREAM", form="unformatted")

read(unit), char

Good luck! By the way, STREAM I/O is really slick.

Jerry
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: reading complex data using implied do loops
Next: FTP libraries