Memory Errors
Nancy Palmquist
nlp at vss3.com
Wed Oct 21 06:44:39 PDT 2009
John Esak wrote:
> Hi,
> Yes, seems so different now that this place and the FP Room aren't seemingly
> 24 hour deals. We actually make appointments to go into the FP Room now. At
> least that keeps the core group talking now and again.
>
> I wish I had an answer for you. Have you used the system arrays which tell
> you how many open files and filePro files, etc. are active at that precise
> WRITE. It obviously is a specific WRITE like "WRITE alisa". I wonder if
> doing a generic CLOSE just before the WRITE would do anything. Of course
> opening the next files will take a bit longer, but if it clears up the
> problem until you can figure out what it is... Why not.
>
> JOhn
>
>
John,
Nice to get an answer from you. I have not checked the open files
array, but the fact that the problem will go away for long periods of
time, seems to suggest that it is not open files limits.
I have revised the processing as much as possible and we do have a CLOSE
to the file in question, I open and lock the file, I change the one
field that causes problems and then
it crashes on the WRITE file command.
I have pinned it down that much. It used to leave the index corrupted
and it would report a deleted key error on that exact record if I
updated it again.
But this last round of errors does not seem to leave the index with a
deleted key error, but I am sure it is still corrupted.
Out of thousands of hits against this file every day, when it is
horrible it crashes maybe 50 times. Annoying to the people trying to
work, since it is in a data entry table, but hard to catch in a debug
situation. I can not reproduce it in a controlled setting. I have
added LOGTEXT lines at critical places throughout the table and they
write a log that I can review to find the location of the crash. The
LOGTEXT entries were positioned until I could narrow the flaw down to 4
lines. Although occasionally it does occur in another location, 98% of
the crashes are in those 4 lines exactly at the WRITE line. It always
seems to be related to a WRITE to the same file.
BTW - the data has been written to the record, one of the two indexes
that are affected will not be fixed. That is how close I have this
pinned. Once it starts happening, the corruption to the indexes, I
think make this cascade into a mess in a few hours. It takes 12 minutes
to rebuild the indexes on this file, and 30 people have to sit on their
hands (just getting them all out and keeping them out is difficult.)
Thanks for the suggestions.
Nancy
>> -----Original Message-----
>> From: filepro-list-bounces+john=valar.com at lists.celestial.com
>> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
>>
> m] On Behalf Of Nancy Palmquist
>
>> Sent: Tuesday, October 20, 2009 5:58 PM
>> To: filePro List
>> Subject: Memory Errors
>>
>> 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
>>
>> --
>> Nancy Palmquist MOS & filePro Training Available
>> Virtual Software Systems Web Based Training and Consulting
>> PHONE: (412) 835-9417 Web site: http://www.vss3.com
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>
>>
>
>
--
Nancy Palmquist MOS & filePro Training Available
Virtual Software Systems Web Based Training and Consulting
PHONE: (412) 835-9417 Web site: http://www.vss3.com
More information about the Filepro-list
mailing list