Memory Errors

[Boaz Bezborodko]

> Date: Tue, 20 Oct 2009 17:57:30 -0400
> From: Nancy Palmquist <nlp at vss3.com>
> Subject: Memory Errors
> To: filePro List <filepro-list at lists.celestial.com>
> Message-ID: <4ADE324A.5010208 at vss3.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I need some suggestions.  On a Windows Server 2003, with XP clients, we 
> have a situation that keeps returning.  We are running filePro 5.0 and 
> filePro 5.0 Odbc versions on this system.
>
> Dclerk is throwing memory errors at a point in the processing where I 
> open a file, change one piece of data and write the data.  The data is 
> included in 2 indexes.  I know if we rebuild these two indexes the 
> memory errors go away for some time.
>
> The indexes in the file that throws the memory errors are rebuilt every 
> night, so we start with clean indexes each day.  Once it throws a memory 
> error, it seems that we start getting them often until we can rebuild 
> the indexes.
>
> I have narrowed the logic that causes the memory errors to a very narrow 
> 4 lines.
>
> Open a file with a protect (lock).
>
> write the one piece of data
>
> WRITE the file to send the data and unlock the record.
>
> The Write command seems to be what causes the memory error.  The very 
> next line, is not executed.
>
> I open and update data in the same file many times before this crash.  I 
> actually write all the previous data, and then reopen the same record 
> before this memory error to make sure I had everything working.
>
> What I suspect:
> 1)  Some kind of I/O issue with the Server.  How can that be tested?  
> Are there logs or something else I can watch to see what is going on?
>
> 2)  Some kind of switch fault.  We have seen this come and go over the 
> last year, and it always seems to be bad for a while and then a faulty 
> switch is replaced and it works wonderful for months.  How can that be 
> tested?
>
> I added some SLEEP commands around this logic to try to give the Server 
> time to handle the I/O.  I find that sometimes this helps with issues 
> like this.  filePro is so fast, I think the Windows server can not keep 
> up.  Usually do not see this kind of thing on my Unix/Linux stuff.
>
> Anyone got an idea or two I can look at?  It would be appreciated.  I 
> really think since it comes and goes, it is more likely to be related to 
> hardware, network, or OS. 
>
> I have studied the processing many times over the years we have been 
> doing this and I think it would break all the time if I missed 
> something, but I am certainly not perfect so that might also be 
> possible.  ;-)
>
> Anyway, I am tired of seeing the list so empty.  I feel so all alone 
> these days.
>
> Nancy
>
>   
I experienced some problems similar to this a while back running FP off 
a Samba server.  Since Samba emulates a Windows server the issues might 
be related.  In my case there was a problem where the Samba server was 
going down and restarting due to some I/O issue.  IIRC the issue 
occurred when FP would write to the Samba server when it was down and 
the connection was broken.  Samba was good about maintaining connections 
after a restart, but this didn't help if the communication occurred 
while it was down.  Once I resolved the problems with the Samba server 
going down (for some reason it didn't like communicating on port 445 
with the clients) it stopped going down and the problems went away.

I doubt that the problems are the same, but it might help you target the 
cause.

Boaz