re Text file database, moving from Mac OsX to windows

[Martin Baxter]

>Philippe Giraudet wrote:
>Hello
>
>Thanks to Robert Brenstein and Klaus Major for their answers.
>The question is not an encoding problem and no more a corruption of
>data because of simultaneous writing access, because I still only
>tested it in mono user access, on windows. I just realise, with what
>Robert says that the corruption by simultaneous writing access will be
>my next problem ;-)))) ... ;-(
>the problem is that when you enter a command line such as
>
>write appointment to file Pathway at
>(1001+dayLength*(dayNumber-1)+225+(RoomNum-1)*4001+(AppNum-1)*100-1)
>
>It writes at the rigth place  on Mac
>
>and at the wrong place on windows!
>
>I believe it can't be an error on calculation of the first char:
>(1001+dayLength*(dayNumber-1)+225+(RoomNum-1)*4001+(AppNum-1)*100-1)
>
>I prefer to suppose it is a quetion of length of the chain I write : if
>some chars like return or even tab are not counted , in a 8MB text
>file, it makes a great difference at the end of the file.
>

Phillipe,

This is only a guess, as I'm not clear what is happening in your situation,
but might your problem be related to the different line delimiters on the
platforms in question? Mac uses a single character - ASCII 13, while
windows uses two characters - ASCII 13 + ASCII 10 (CRLF)?

I'm theorising that if, for example, <appointment> contains line returns,
these might be automatically translated from RR's internal delimiter (ASCII
10) to windows CRLF when writing on that platform. This might cause an
increasing discrepancy if your calculations assume that the line delimiter
is a single byte.

If this might be the problem, you might avoid it if you read and write as
binary, as Revolution's internal ASCII 10 line returns will then be written
to file unmodified.

HTH

Martin Baxter