I have a site that uses memoRead to get files that have been created with 
Var2Bin() - this has worked well for a long time.

Just today Memoread() started failing because the subsequent Bin2Var() 
generated an "Internal Data Structures Corrupted" Message. The same files 
were read correctly on my machine and so the files were not corrupt 
themselves.

I have noticed rarely that MemoRead doesn't always work correctly in other 
situations. I have other text files which contain printing instructions for 
special documents - sometimes the behaviour of these documents changes and 
the way I prevent that is to make multiple copies of commands in these text 
files. For some reason the whole text file is not always loaded into the 
memory variable allocated to it and it was missing some of the last lines of 
the file.

In one other situation where it is reading a text file with structured data, 
it even more rarely fails to read it at all.

In the first case above, I installed some error handling and then used 
Fopen, FRead, Fseek commands as a backup method and this worked on all files 
bar one.

The temperamental behaviour of MemoRead suggests that it is affected by the 
environment - I have suspected for some time that the way that Windows is 
built creates ways for one process to interfere with another when they 
should all act as black boxes.

Because this effect is intermittent, I cannot reproduce it but hopefully 
Alaska may find a way to make Memoread more reliable.

Cheers

Phil Jackson

Phil,

> Just today Memoread() started failing because the subsequent Bin2Var() 
> generated an "Internal Data Structures Corrupted" Message.

IMO Memoread() is pretty stable. It reads an entire file into memory and is 
the fastest way of doing so.

If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
Bin2Var(), I'd suspect the file data being corrupted.

If the file is not corrupted, it might store complex data (array, codeblock, 
object) containing nested complex data that were lost upon initial 
Var2Bin().

Make sure that the file contains a valid string that can be decoded with 
Bin2Var().

HTH,
--
Hannes


"Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
news:6a109012$6f48cf3f$639@news.alaska-software.com...
>I have a site that uses memoRead to get files that have been created with 
>Var2Bin() - this has worked well for a long time.
>
> Just today Memoread() started failing because the subsequent Bin2Var() 
> generated an "Internal Data Structures Corrupted" Message. The same files 
> were read correctly on my machine and so the files were not corrupt 
> themselves.
>
> I have noticed rarely that MemoRead doesn't always work correctly in other 
> situations. I have other text files which contain printing instructions 
> for special documents - sometimes the behaviour of these documents changes 
> and the way I prevent that is to make multiple copies of commands in these 
> text files. For some reason the whole text file is not always loaded into 
> the memory variable allocated to it and it was missing some of the last 
> lines of the file.
>
> In one other situation where it is reading a text file with structured 
> data, it even more rarely fails to read it at all.
>
> In the first case above, I installed some error handling and then used 
> Fopen, FRead, Fseek commands as a backup method and this worked on all 
> files bar one.
>
> The temperamental behaviour of MemoRead suggests that it is affected by 
> the environment - I have suspected for some time that the way that Windows 
> is built creates ways for one process to interfere with another when they 
> should all act as black boxes.
>
> Because this effect is intermittent, I cannot reproduce it but hopefully 
> Alaska may find a way to make Memoread more reliable.
>
> Cheers
>
> Phil Jackson
>

Doesn't memo read assume a text file?? It might have problems with
things like CHR(0) that might be in binary data. For binary data I would
use fOpen() and fRead() rather then a memo function.

Jim

Hannes Ziegler wrote:
> Phil,
> 
>> Just today Memoread() started failing because the subsequent Bin2Var() 
>> generated an "Internal Data Structures Corrupted" Message.
> 
> IMO Memoread() is pretty stable. It reads an entire file into memory and is 
> the fastest way of doing so.
> 
> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
> Bin2Var(), I'd suspect the file data being corrupted.
> 
> If the file is not corrupted, it might store complex data (array, codeblock, 
> object) containing nested complex data that were lost upon initial 
> Var2Bin().
> 
> Make sure that the file contains a valid string that can be decoded with 
> Bin2Var().
> 
> HTH,
> --
> Hannes
> 
> 
> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>> I have a site that uses memoRead to get files that have been created with 
>> Var2Bin() - this has worked well for a long time.
>>
>> Just today Memoread() started failing because the subsequent Bin2Var() 
>> generated an "Internal Data Structures Corrupted" Message. The same files 
>> were read correctly on my machine and so the files were not corrupt 
>> themselves.
>>
>> I have noticed rarely that MemoRead doesn't always work correctly in other 
>> situations. I have other text files which contain printing instructions 
>> for special documents - sometimes the behaviour of these documents changes 
>> and the way I prevent that is to make multiple copies of commands in these 
>> text files. For some reason the whole text file is not always loaded into 
>> the memory variable allocated to it and it was missing some of the last 
>> lines of the file.
>>
>> In one other situation where it is reading a text file with structured 
>> data, it even more rarely fails to read it at all.
>>
>> In the first case above, I installed some error handling and then used 
>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>> files bar one.
>>
>> The temperamental behaviour of MemoRead suggests that it is affected by 
>> the environment - I have suspected for some time that the way that Windows 
>> is built creates ways for one process to interfere with another when they 
>> should all act as black boxes.
>>
>> Because this effect is intermittent, I cannot reproduce it but hopefully 
>> Alaska may find a way to make Memoread more reliable.
>>
>> Cheers
>>
>> Phil Jackson
>>
> 
>

Hi

We used memoread allot in our app, and found it not to be stable as 
well.  We have now replaced it with fread and fwrite.  We have found at 
various times that it only reads some of the data.  We could never 
replicate it in our office, but could clearly see the effects at sites. 
  I guess this could be the problem here as well.  U suggest to ditch 
memoread and use fread instead.  Since the change we did not have much 
other problems, although I do think there is OS issues here as well with 
multiple workstations accessing the file at the same time.

Regards

James Loughner wrote:
> Doesn't memo read assume a text file?? It might have problems with
> things like CHR(0) that might be in binary data. For binary data I would
> use fOpen() and fRead() rather then a memo function.
> 
> Jim
> 
> Hannes Ziegler wrote:
>> Phil,
>>
>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>> generated an "Internal Data Structures Corrupted" Message.
>> IMO Memoread() is pretty stable. It reads an entire file into memory and is 
>> the fastest way of doing so.
>>
>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>> Bin2Var(), I'd suspect the file data being corrupted.
>>
>> If the file is not corrupted, it might store complex data (array, codeblock, 
>> object) containing nested complex data that were lost upon initial 
>> Var2Bin().
>>
>> Make sure that the file contains a valid string that can be decoded with 
>> Bin2Var().
>>
>> HTH,
>> --
>> Hannes
>>
>>
>> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
>> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>>> I have a site that uses memoRead to get files that have been created with 
>>> Var2Bin() - this has worked well for a long time.
>>>
>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>> generated an "Internal Data Structures Corrupted" Message. The same files 
>>> were read correctly on my machine and so the files were not corrupt 
>>> themselves.
>>>
>>> I have noticed rarely that MemoRead doesn't always work correctly in other 
>>> situations. I have other text files which contain printing instructions 
>>> for special documents - sometimes the behaviour of these documents changes 
>>> and the way I prevent that is to make multiple copies of commands in these 
>>> text files. For some reason the whole text file is not always loaded into 
>>> the memory variable allocated to it and it was missing some of the last 
>>> lines of the file.
>>>
>>> In one other situation where it is reading a text file with structured 
>>> data, it even more rarely fails to read it at all.
>>>
>>> In the first case above, I installed some error handling and then used 
>>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>>> files bar one.
>>>
>>> The temperamental behaviour of MemoRead suggests that it is affected by 
>>> the environment - I have suspected for some time that the way that Windows 
>>> is built creates ways for one process to interfere with another when they 
>>> should all act as black boxes.
>>>
>>> Because this effect is intermittent, I cannot reproduce it but hopefully 
>>> Alaska may find a way to make Memoread more reliable.
>>>
>>> Cheers
>>>
>>> Phil Jackson
>>>
>>

Hi

We used memoread allot in our app, and found it not to be stable as 
well.  We have now replaced it with fread and fwrite.  We have found at 
various times that it only reads some of the data.  We could never 
replicate it in our office, but could clearly see the effects at sites. 
  I guess this could be the problem here as well.  U suggest to ditch 
memoread and use fread instead.  Since the change we did not have much 
other problems, although I do think there is OS issues here as well with 
multiple workstations accessing the file at the same time.

Regards

James Loughner wrote:
> Doesn't memo read assume a text file?? It might have problems with
> things like CHR(0) that might be in binary data. For binary data I would
> use fOpen() and fRead() rather then a memo function.
> 
> Jim
> 
> Hannes Ziegler wrote:
>> Phil,
>>
>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>> generated an "Internal Data Structures Corrupted" Message.
>> IMO Memoread() is pretty stable. It reads an entire file into memory and is 
>> the fastest way of doing so.
>>
>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>> Bin2Var(), I'd suspect the file data being corrupted.
>>
>> If the file is not corrupted, it might store complex data (array, codeblock, 
>> object) containing nested complex data that were lost upon initial 
>> Var2Bin().
>>
>> Make sure that the file contains a valid string that can be decoded with 
>> Bin2Var().
>>
>> HTH,
>> --
>> Hannes
>>
>>

Hi Johan

I sometimes think I am the only one that gets some of these curly ones. It's 
relieving to know that others do too. I'm of the same opinion - this has 
worked at one site and one day stopped working and there hadn't been a 
program change for about 5 days. I will stop using Memoread where practical 
and change to FOpen/FRead

Cheers

Phil Jackson

"Johan Droskie" <Johan@NoMoreSpam_Hotsoft.Com> wrote in message 
news:47551F47.1080407@NoMoreSpam_Hotsoft.Com...
> Hi
>
> We used memoread allot in our app, and found it not to be stable as well. 
> We have now replaced it with fread and fwrite.  We have found at various 
> times that it only reads some of the data.  We could never replicate it in 
> our office, but could clearly see the effects at sites. I guess this could 
> be the problem here as well.  U suggest to ditch memoread and use fread 
> instead.  Since the change we did not have much other problems, although I 
> do think there is OS issues here as well with multiple workstations 
> accessing the file at the same time.
>
> Regards
>
> James Loughner wrote:
>> Doesn't memo read assume a text file?? It might have problems with
>> things like CHR(0) that might be in binary data. For binary data I would
>> use fOpen() and fRead() rather then a memo function.
>>
>> Jim
>>
>> Hannes Ziegler wrote:
>>> Phil,
>>>
>>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>>> generated an "Internal Data Structures Corrupted" Message.
>>> IMO Memoread() is pretty stable. It reads an entire file into memory and 
>>> is the fastest way of doing so.
>>>
>>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>>> Bin2Var(), I'd suspect the file data being corrupted.
>>>
>>> If the file is not corrupted, it might store complex data (array, 
>>> codeblock, object) containing nested complex data that were lost upon 
>>> initial Var2Bin().
>>>
>>> Make sure that the file contains a valid string that can be decoded with 
>>> Bin2Var().
>>>
>>> HTH,
>>> --
>>> Hannes
>>>
>>>

Hi Hannes

I can read the same file from my machine without any problems.

Cheers

Phil
"Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
news:72e849a9$763ae0a0$679@news.alaska-software.com...
> Phil,
>
>> Just today Memoread() started failing because the subsequent Bin2Var() 
>> generated an "Internal Data Structures Corrupted" Message.
>
> IMO Memoread() is pretty stable. It reads an entire file into memory and 
> is the fastest way of doing so.
>
> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
> Bin2Var(), I'd suspect the file data being corrupted.
>
> If the file is not corrupted, it might store complex data (array, 
> codeblock, object) containing nested complex data that were lost upon 
> initial Var2Bin().
>
> Make sure that the file contains a valid string that can be decoded with 
> Bin2Var().
>
> HTH,
> --
> Hannes
>
>
> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>>I have a site that uses memoRead to get files that have been created with 
>>Var2Bin() - this has worked well for a long time.
>>
>> Just today Memoread() started failing because the subsequent Bin2Var() 
>> generated an "Internal Data Structures Corrupted" Message. The same files 
>> were read correctly on my machine and so the files were not corrupt 
>> themselves.
>>
>> I have noticed rarely that MemoRead doesn't always work correctly in 
>> other situations. I have other text files which contain printing 
>> instructions for special documents - sometimes the behaviour of these 
>> documents changes and the way I prevent that is to make multiple copies 
>> of commands in these text files. For some reason the whole text file is 
>> not always loaded into the memory variable allocated to it and it was 
>> missing some of the last lines of the file.
>>
>> In one other situation where it is reading a text file with structured 
>> data, it even more rarely fails to read it at all.
>>
>> In the first case above, I installed some error handling and then used 
>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>> files bar one.
>>
>> The temperamental behaviour of MemoRead suggests that it is affected by 
>> the environment - I have suspected for some time that the way that 
>> Windows is built creates ways for one process to interfere with another 
>> when they should all act as black boxes.
>>
>> Because this effect is intermittent, I cannot reproduce it but hopefully 
>> Alaska may find a way to make Memoread more reliable.
>>
>> Cheers
>>
>> Phil Jackson
>>
>
>

Phil,

> I can read the same file from my machine without any problems.

I wonder how you write your Var2Bin() data into a file ...

I assume that you use MemoWrit() to store Var2Bin()ed data into a file, and 
MemoRead() this file lateron to restore the data with Bin2Var().

IF <I am NOT mistaken>
   you are likely to ask for nothing but trouble ...
   CONTINUE reading
ELSE
   Ignore the rest of my post ...
   SKIP to the next message
ENDIF

MemoRead() reads an entire stream of data from file into memory (This 
function works reliably. I have never encountered a problem with it).

When you use MemoWrit() to write Var2Bin() data to a file, you must be aware 
of the final CTRL-Z byte (Chr(26)) added by MemoWrit() (Clipper 
compatibility pays its toll).

This extra Chr(26) can spoil your entire binary data when you re-read it 
with MemoRead() and pass it on to Bin2Var().

I have no clue how the Bin2Var() function deals with a final CTRL-Z byte, 
but I highly suspect CTRL-Z to be a major cause of IDSCs when MemoRead() 
data is passed to Bin2Var().

My suggestion:

_never_ever_ use MemoWrit() to write binary data to a file. (MemoWrit() 
alters data by adding CTRL-Z). Use FWrite() instead.

There is no problem to use MemoRead() for loading binary data from a file, 
since MemoRead() does not alter data.

Regards,
--
Hannes

> "Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
> news:72e849a9$763ae0a0$679@news.alaska-software.com...
>> Phil,
>>
>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>> generated an "Internal Data Structures Corrupted" Message.
>>
>> IMO Memoread() is pretty stable. It reads an entire file into memory and 
>> is the fastest way of doing so.
>>
>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>> Bin2Var(), I'd suspect the file data being corrupted.
>>
>> If the file is not corrupted, it might store complex data (array, 
>> codeblock, object) containing nested complex data that were lost upon 
>> initial Var2Bin().
>>
>> Make sure that the file contains a valid string that can be decoded with 
>> Bin2Var().
>>
>> HTH,
>> --
>> Hannes
>>
>>
>> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
>> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>>>I have a site that uses memoRead to get files that have been created with 
>>>Var2Bin() - this has worked well for a long time.
>>>
>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>> generated an "Internal Data Structures Corrupted" Message. The same 
>>> files were read correctly on my machine and so the files were not 
>>> corrupt themselves.
>>>
>>> I have noticed rarely that MemoRead doesn't always work correctly in 
>>> other situations. I have other text files which contain printing 
>>> instructions for special documents - sometimes the behaviour of these 
>>> documents changes and the way I prevent that is to make multiple copies 
>>> of commands in these text files. For some reason the whole text file is 
>>> not always loaded into the memory variable allocated to it and it was 
>>> missing some of the last lines of the file.
>>>
>>> In one other situation where it is reading a text file with structured 
>>> data, it even more rarely fails to read it at all.
>>>
>>> In the first case above, I installed some error handling and then used 
>>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>>> files bar one.
>>>
>>> The temperamental behaviour of MemoRead suggests that it is affected by 
>>> the environment - I have suspected for some time that the way that 
>>> Windows is built creates ways for one process to interfere with another 
>>> when they should all act as black boxes.
>>>
>>> Because this effect is intermittent, I cannot reproduce it but hopefully 
>>> Alaska may find a way to make Memoread more reliable.
>>>
>>> Cheers
>>>
>>> Phil Jackson
>>>
>>
>>
>
>

Hi Hannes

I have been creating these files for some time without problem - which 
suggests that Ctrl-Z does not have an impact. I have been using memowrit to 
create them and am aware of the EOF marker. A whole network of computers all 
of a sudden were no longer able to use MemoRead and I switched to FRead as a 
backup. Other sites have never had a problem.

I cannot explain that weird behaviour but MS's design complexity will be an 
ingredient in that behaviour.

I will use FWrite where practical.

Cheers

Phil

I take your point though and will where practical change to FWrite()
"Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
news:7bfdf619$61cddefe$75c9@news.alaska-software.com...
> Phil,
>
>> I can read the same file from my machine without any problems.
>
> I wonder how you write your Var2Bin() data into a file ...
>
> I assume that you use MemoWrit() to store Var2Bin()ed data into a file, 
> and MemoRead() this file lateron to restore the data with Bin2Var().
>
> IF <I am NOT mistaken>
>   you are likely to ask for nothing but trouble ...
>   CONTINUE reading
> ELSE
>   Ignore the rest of my post ...
>   SKIP to the next message
> ENDIF
>
> MemoRead() reads an entire stream of data from file into memory (This 
> function works reliably. I have never encountered a problem with it).
>
> When you use MemoWrit() to write Var2Bin() data to a file, you must be 
> aware of the final CTRL-Z byte (Chr(26)) added by MemoWrit() (Clipper 
> compatibility pays its toll).
>
> This extra Chr(26) can spoil your entire binary data when you re-read it 
> with MemoRead() and pass it on to Bin2Var().
>
> I have no clue how the Bin2Var() function deals with a final CTRL-Z byte, 
> but I highly suspect CTRL-Z to be a major cause of IDSCs when MemoRead() 
> data is passed to Bin2Var().
>
> My suggestion:
>
> _never_ever_ use MemoWrit() to write binary data to a file. (MemoWrit() 
> alters data by adding CTRL-Z). Use FWrite() instead.
>
> There is no problem to use MemoRead() for loading binary data from a file, 
> since MemoRead() does not alter data.
>
> Regards,
> --
> Hannes
>
>> "Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
>> news:72e849a9$763ae0a0$679@news.alaska-software.com...
>>> Phil,
>>>
>>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>>> generated an "Internal Data Structures Corrupted" Message.
>>>
>>> IMO Memoread() is pretty stable. It reads an entire file into memory and 
>>> is the fastest way of doing so.
>>>
>>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>>> Bin2Var(), I'd suspect the file data being corrupted.
>>>
>>> If the file is not corrupted, it might store complex data (array, 
>>> codeblock, object) containing nested complex data that were lost upon 
>>> initial Var2Bin().
>>>
>>> Make sure that the file contains a valid string that can be decoded with 
>>> Bin2Var().
>>>
>>> HTH,
>>> --
>>> Hannes
>>>
>>>
>>> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
>>> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>>>>I have a site that uses memoRead to get files that have been created 
>>>>with Var2Bin() - this has worked well for a long time.
>>>>
>>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>>> generated an "Internal Data Structures Corrupted" Message. The same 
>>>> files were read correctly on my machine and so the files were not 
>>>> corrupt themselves.
>>>>
>>>> I have noticed rarely that MemoRead doesn't always work correctly in 
>>>> other situations. I have other text files which contain printing 
>>>> instructions for special documents - sometimes the behaviour of these 
>>>> documents changes and the way I prevent that is to make multiple copies 
>>>> of commands in these text files. For some reason the whole text file is 
>>>> not always loaded into the memory variable allocated to it and it was 
>>>> missing some of the last lines of the file.
>>>>
>>>> In one other situation where it is reading a text file with structured 
>>>> data, it even more rarely fails to read it at all.
>>>>
>>>> In the first case above, I installed some error handling and then used 
>>>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>>>> files bar one.
>>>>
>>>> The temperamental behaviour of MemoRead suggests that it is affected by 
>>>> the environment - I have suspected for some time that the way that 
>>>> Windows is built creates ways for one process to interfere with another 
>>>> when they should all act as black boxes.
>>>>
>>>> Because this effect is intermittent, I cannot reproduce it but 
>>>> hopefully Alaska may find a way to make Memoread more reliable.
>>>>
>>>> Cheers
>>>>
>>>> Phil Jackson
>>>>
>>>
>>>
>>
>>
>
>

The the binary contains a ctrl-Z it can stop the reading of the file
data at that point. Look at the problem data with a binary editor to see
if you have embedded ctrl-Z's not at the EOF

Jim


Phil Jackson wrote:
> Hi Hannes
> 
> I have been creating these files for some time without problem - which 
> suggests that Ctrl-Z does not have an impact. I have been using memowrit to 
> create them and am aware of the EOF marker. A whole network of computers all 
> of a sudden were no longer able to use MemoRead and I switched to FRead as a 
> backup. Other sites have never had a problem.
> 
> I cannot explain that weird behaviour but MS's design complexity will be an 
> ingredient in that behaviour.
> 
> I will use FWrite where practical.
> 
> Cheers
> 
> Phil
> 
> I take your point though and will where practical change to FWrite()
> "Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
> news:7bfdf619$61cddefe$75c9@news.alaska-software.com...
>> Phil,
>>
>>> I can read the same file from my machine without any problems.
>> I wonder how you write your Var2Bin() data into a file ...
>>
>> I assume that you use MemoWrit() to store Var2Bin()ed data into a file, 
>> and MemoRead() this file lateron to restore the data with Bin2Var().
>>
>> IF <I am NOT mistaken>
>>   you are likely to ask for nothing but trouble ...
>>   CONTINUE reading
>> ELSE
>>   Ignore the rest of my post ...
>>   SKIP to the next message
>> ENDIF
>>
>> MemoRead() reads an entire stream of data from file into memory (This 
>> function works reliably. I have never encountered a problem with it).
>>
>> When you use MemoWrit() to write Var2Bin() data to a file, you must be 
>> aware of the final CTRL-Z byte (Chr(26)) added by MemoWrit() (Clipper 
>> compatibility pays its toll).
>>
>> This extra Chr(26) can spoil your entire binary data when you re-read it 
>> with MemoRead() and pass it on to Bin2Var().
>>
>> I have no clue how the Bin2Var() function deals with a final CTRL-Z byte, 
>> but I highly suspect CTRL-Z to be a major cause of IDSCs when MemoRead() 
>> data is passed to Bin2Var().
>>
>> My suggestion:
>>
>> _never_ever_ use MemoWrit() to write binary data to a file. (MemoWrit() 
>> alters data by adding CTRL-Z). Use FWrite() instead.
>>
>> There is no problem to use MemoRead() for loading binary data from a file, 
>> since MemoRead() does not alter data.
>>
>> Regards,
>> --
>> Hannes
>>
>>> "Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
>>> news:72e849a9$763ae0a0$679@news.alaska-software.com...
>>>> Phil,
>>>>
>>>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>>>> generated an "Internal Data Structures Corrupted" Message.
>>>> IMO Memoread() is pretty stable. It reads an entire file into memory and 
>>>> is the fastest way of doing so.
>>>>
>>>> If you MemoRead() a Var2Bin() string from a file and get an IDSC with 
>>>> Bin2Var(), I'd suspect the file data being corrupted.
>>>>
>>>> If the file is not corrupted, it might store complex data (array, 
>>>> codeblock, object) containing nested complex data that were lost upon 
>>>> initial Var2Bin().
>>>>
>>>> Make sure that the file contains a valid string that can be decoded with 
>>>> Bin2Var().
>>>>
>>>> HTH,
>>>> --
>>>> Hannes
>>>>
>>>>
>>>> "Phil Jackson" <sapient@clear.net.nz> schrieb im Newsbeitrag 
>>>> news:6a109012$6f48cf3f$639@news.alaska-software.com...
>>>>> I have a site that uses memoRead to get files that have been created 
>>>>> with Var2Bin() - this has worked well for a long time.
>>>>>
>>>>> Just today Memoread() started failing because the subsequent Bin2Var() 
>>>>> generated an "Internal Data Structures Corrupted" Message. The same 
>>>>> files were read correctly on my machine and so the files were not 
>>>>> corrupt themselves.
>>>>>
>>>>> I have noticed rarely that MemoRead doesn't always work correctly in 
>>>>> other situations. I have other text files which contain printing 
>>>>> instructions for special documents - sometimes the behaviour of these 
>>>>> documents changes and the way I prevent that is to make multiple copies 
>>>>> of commands in these text files. For some reason the whole text file is 
>>>>> not always loaded into the memory variable allocated to it and it was 
>>>>> missing some of the last lines of the file.
>>>>>
>>>>> In one other situation where it is reading a text file with structured 
>>>>> data, it even more rarely fails to read it at all.
>>>>>
>>>>> In the first case above, I installed some error handling and then used 
>>>>> Fopen, FRead, Fseek commands as a backup method and this worked on all 
>>>>> files bar one.
>>>>>
>>>>> The temperamental behaviour of MemoRead suggests that it is affected by 
>>>>> the environment - I have suspected for some time that the way that 
>>>>> Windows is built creates ways for one process to interfere with another 
>>>>> when they should all act as black boxes.
>>>>>
>>>>> Because this effect is intermittent, I cannot reproduce it but 
>>>>> hopefully Alaska may find a way to make Memoread more reliable.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Phil Jackson
>>>>>
>>>>
>>>
>>
> 
>

Phil,

> I have been creating these files for some time without problem - which 
> suggests that Ctrl-Z does not have an impact. I have been using memowrit 
> to create them and am aware of the EOF marker. A whole network of 
> computers all of a sudden were no longer able to use MemoRead and I 
> switched to FRead as a backup. Other sites have never had a problem.
>
> I cannot explain that weird behaviour but MS's design complexity will be 
> an ingredient in that behaviour.
>
> I will use FWrite where practical.

Well, my suggestion tried to eliminate all possible sources of errors on 
your side, one of which is CTRL-Z combined with binary data 
(Var2Bin()/Bin2Var()).

I'm currently having an IDSC problem myself with well-designed code that 
used to work for years. All over a sudden it stopped working. 
(MemoRead/MemoWrit is not involved).

Unfortunately, I am a disgraced person at Alaska, thus the Alaska guys 
neither answer a technical support question nor are they willing to 
investigate a reproducable IDSC.

Regards,
--
Hannes

Hello Phil,

I agree with James that memo????() functions are not documented for binary 
support and low level file functions are more appropriate.  However, I did 
test memoread with all binary characters (0-255) in pairs without any problem.

One thing that should be added to this topic is what reader/writer synchronization 
you are using.  The memo????() functions are unclear regarding conflict, 
but the memoread() is clear that an empty string will be returned if it cannot 
access the file.

Contrary to the memoread() documentation, I doubt that "Any size file can 
be read by MemoRead()" is an accurate statement.  But then I use 10GB+ size 
files on a regular basis.

FWIW, memoread() is very easy to implement using low level file functions 
with concurrency and retries.  Then #pragma map makes it very easy to redirect 
your current and future memoread()s to the robust implementation without 
abandoning the ease and familiarity of the syntax.

Finally, since Bin2Var() is likely to fault on any binary difference from 
the Var2Bin() output and result in non-graceful application failure, I would 
suggest that you add some error detection (CRC, Hash, etc.) to your binary 
data.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Hi Rodd

You have raised a point about synchronisation which is something I need to 
consider. The EDI files being read (the Var2Bin) ones are only read by one 
person who gets control but in other areas I will need to make sure that if 
I change to Fread that I make it shareable so others are not affected if 
they try to read the same file.

Cheers

Phil Jackson

"Rodd Graham" <rgraham@grahamautomation.com> wrote in message 
news:6c56a922356268ca04a6b3715049@news.alaska-software.com...
> Hello Phil,
>
> I agree with James that memo????() functions are not documented for binary 
> support and low level file functions are more appropriate.  However, I did 
> test memoread with all binary characters (0-255) in pairs without any 
> problem.
>
> One thing that should be added to this topic is what reader/writer 
> synchronization you are using.  The memo????() functions are unclear 
> regarding conflict, but the memoread() is clear that an empty string will 
> be returned if it cannot access the file.
>
> Contrary to the memoread() documentation, I doubt that "Any size file can 
> be read by MemoRead()" is an accurate statement.  But then I use 10GB+ 
> size files on a regular basis.
>
> FWIW, memoread() is very easy to implement using low level file functions 
> with concurrency and retries.  Then #pragma map makes it very easy to 
> redirect your current and future memoread()s to the robust implementation 
> without abandoning the ease and familiarity of the syntax.
>
> Finally, since Bin2Var() is likely to fault on any binary difference from 
> the Var2Bin() output and result in non-graceful application failure, I 
> would suggest that you add some error detection (CRC, Hash, etc.) to your 
> binary data.
>
> Regards,
>
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
>
>

Hi Rodd,

> Contrary to the memoread() documentation, I doubt that "Any size file can 
> be read by MemoRead()" is an accurate statement.  But then I use 10GB+ 
> size files on a regular basis.

What do you mean with "10GB+ size files"?

Are you telling that you have successfully MemoRead() a file > 1 GB?

What is your largest file with MemoRead() ?

Wondering,
--
Hannes

PS: I happen to have used MemoRead() successfully with files of up to 1.5 MB 
in size.
    Both: textual and binary data.

Hello Hannes,

>> Contrary to the memoread() documentation, I doubt that "Any size file
>> can be read by MemoRead()" is an accurate statement.  But then I use
>> 10GB+ size files on a regular basis.
>> 
> What do you mean with "10GB+ size files"?
> 
> Are you telling that you have successfully MemoRead() a file > 1 GB?
> 
> What is your largest file with MemoRead() ?

No, no.  Just observing that the concept of memoread()ing an unlimited file 
size is in obvious competition with the 2GB memory space of a Win32 process 
(or in fact any finite memory machine).  I was trying to humorously suggest 
that I must be the only one using files larger than the Win32 memory space.

It is funny how my original Clipper apps that lived within 640K grew to require 
the 64MB Blinker space and continued to grow to require the 2GB Win32 Xbase++ 
space.  In fact, it was the 64MB Blinker limit that forced me to search for 
alternatives and led me to Xbase++.

I currently estimate my usage around 200-400MB and wonder when the 2GB space 
will no longer be enough.  Thankfully Win64 raises the bar again and hopefully 
64bit Xbase++ will arrive before I reach the Win32 limit.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Hi Rodd,

>It is funny how my original Clipper apps that lived within 640K grew to 
>require the 64MB Blinker space and continued to grow to require the 2GB 
>Win32 Xbase++ space.

Welcome to the club .

For me it is amazing how hardware continued to improve. My first 286 PC had 
a "monster" 20MB harddisk. Nowadays I am enabled to put my entire digital 
working environment including OS into my pocket with a 2 GB USB stick.

FWIW, IMO hardware improves faster than software.

Regards,
--
Hannes

Hello Hannes,

> FWIW, IMO hardware improves faster than software.

This is true, but changing.  As hardware has reached silicon performance 
limits, I believe that software is now the focus for improvements.  Hardware 
is still growing in width (bits and cores), but this requires new software 
implementations to take advantage of unlike the growth in Ghz.  

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Rodd Graham wrote:

> This is true, but changing.  As hardware has reached silicon performance 
> limits, I believe that software is now the focus for improvements.  Hardware 
> is still growing in width (bits and cores), but this requires new software 
> implementations to take advantage of unlike the growth in Ghz.  

I do not think hardware has reached its limits yet - but instead of
increasing the clock rate of modern processors, the processor manufacturers
will use higher densities (45 nm process being state of the art right now,
12 nm until 2013) to produce different processor architectures like
multi-core CPUs.

regards
Thomas

Hello Thomas,

>> This is true, but changing.  As hardware has reached silicon
>> performance limits, I believe that software is now the focus for
>> improvements.  Hardware is still growing in width (bits and cores),
>> but this requires new software implementations to take advantage of
>> unlike the growth in Ghz.
>> 
> I do not think hardware has reached its limits yet - but instead of
> increasing the clock rate of modern processors, the processor
> manufacturers will use higher densities (45 nm process being state of
> the art right now, 12 nm until 2013) to produce different processor
> architectures like multi-core CPUs.

I concur that hardware continues to improve.  My original point was that 
without a clock rate increase or reduction in cycles per instruction, existing 
applications cannot see much increased performance unless they can take advantage 
of parallelism of threads or data paths.  Xbase++ is particularly limited 
since the process must have single processor core affinity in order to be 
reliable.

Regardless, many application goals have sequential requirements that limits 
their ability to take advantage of parallelism.

This is why I believe that software must be the focus to increase processing 
thoroughput going forward.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC