Problem with MEMO fields

[John Esak]

I don't often do this. In fact, I can't remember a time I ever did it.
However, something happened to me over the weekend that is worth just
describing... without any supporting details. (Although, I do have an exact
copy of the files before I made the offending change, and I can duplicate it
at will, to show to support at fptech.com. Which I may do, if they want it, I
personally do not need it anymore... for obvious reasons, and it is a huge
set of files... HUGE.)

Here is the scenario, exactly.

1) while no one was working this holiday weekend, I defined a MEMO field in
each of 4 related filePro files, npio, npiopending, npioarch, and npis. I
backed up the files before I added the fields. Not too important in this
instance.

2) This morning, I was awakened by a slew of people telling me that the
npiopending file, and the npio file were "not working". They would add an
entire record, press ESC ESC, and the computer would BEEP and they were
brought back to their menus. When they checked, the records had not been
stored. An obvious SEGV to my thinking.  I put some debugs here and there in
the two different tables... but they arrived at a CALL table, and BANG they
SEGV'd without even giving me the chance to "see" what was going on.

It was crunch time, orders have to go in without delay... I simply could not
figure out what was wrong. (and I'm fairly good at this stuff... :-)
Anyway, I knew that the ONLY change I had made to these 4 files was the
adding of the MEMO field... like this:


  323  Note_field (fp memo type)    16 MEMO


I webt into ddefine on the first file and removed the field. The problem
immediately vanished!  Before I could get to the next file, one of the girls
came in and said, it is STILL broken, but now at a different place.  I
looked, and the code was doing a lookup to one of the other files which had
the newly added MEMO field in it... same SEGV without any indication of why.
At this point, I quickly got everyone out of that other file and removed the
MEMO field from it. The process which had been failing immediately started
to work again.  Needless to say, I rushed to the other files and removed the
MEMO fields from them as well. No more problems today since then.

Okay, why am I reporting this in this way, without much for anyone to pin a
caution on, or any precise code to show that you might avoid? Only for the
simple reason that it happened to me and it shouldn't have...  I am always
the staunchest support of filePro, always defending that I have never seen
some of the problems many see. I still intend to do this. If I can't
duplicate a problem,, I have no way of confirming that the problem is
filepro-based.  However,  the opposite holds true. If I simply add a field
to a filePro file and immediately records can't be added to the file, there
is no other conclusion to draw, other than filePro is doing something wrong.

Now, maybe my code (which is decades old in this case) is doing something
wrong to point up the problem...  I was wondering what happens if you
overlay an array over some fields and in the middle of that area you add a
memo field... would this cause a problem?  No time to test out theories
today, and this is now the third time I have made an effort to implement
MEMO fields, each time bringing me to a stopping point... mostly not being
able to print them easily.

Anyway, just wanted one time to say, Hey I had a real problem, and it should
not have happened.

Don't want anyone to think I simply talk about the good things of filePro.
:-)

John