Problem with MEMO fields

[John Esak]

> -----Original Message-----
> From: ivan chason [mailto:deweyweekender at yahoo.com]
> Sent: Thursday, September 08, 2005 11:38 AM
> To: john at valar.com
> Subject: Re: Problem with MEMO fields
>
>
> In case there are more concerns with this or if this
> helps to solve any issues.
> We have an employee file that has a memo field and we
> have been archiving them for years.  Well, not for
> years with the memo field, but for about a year.  Just
> recently we ran into a SEGV while trying to archive
> these files.  If files were deleted that had the memo
> field filled in then everything ran fine, but if the
> memo field had anything in it then the SEGV was back
> again.
>
> Field is: (16,MEMO)
>
> So what gives?
> We did just recently upgrade to filepro 5.0.14. Could
> there be an issue in this?
>

Well, at first seeing your name... I thought Joe Chasan might have taught
his six year old how to write in filePro!  Then, I noticed the small
difference. :-)

Anyway, it matters how you were archiving. It so happens that I also archive
and that is exactly when I got SEGV's before... like 2 years ago.  The
interesting thing is that this past weekend I put the memo field into a file
that was not being archived, but it *DID* have something in the process
table similar to how I used to archive things with arrays.  In this case,
there is a 565 element array built on the entire file. I copy the entire
file to a free record when they first enter Update Mode on the record. Then,
when they save the record, I test each field against that record to see
which fields changed, if any. Then I write this field's new value, the old
value, who was making the change, the date and the time to a logfile. I've
been doing this for a decade and a half. This log fiel is one of the most
important tools we have in keeping track of who does what (and then claims
they never did it :-).  Just this last week I pruned this file from 999,997
records (wow, 3 away from a million!) down to about 67,000.

Anyway, by overlaying an array over the whole file... maybe this causes some
problem, because I used to my archiving by building an array over large
parts of the file and copying the array to the archive record.  So, similar
action, similar problem with what happened this week.

It doesn't seem logical to me that there should be *any* problem. A MEMO (or
BLOB) field is just a 16 digit pointer of some kind. I would think all
operations that need to know this is pointing to somewhere in a BLOB file,
should also know what to do with that information. Does this mean that
archived files which include that pointer should point back to the OLD BLOB
file??  I wouldn't think so. Then, do they have to point to the same place
in the NEW (archived record's) BLOB file??? And how could that be, unless
the BLOB files were exactly congruent... which, of course, is impossible. My
best guess is that if and when a record containing a MEMO/BLOB field is
copied to another filePro file, all bets are off and the pointer in that
field should be "reset" in some way to indicate that it really points
nowhere. Or, does anyone think the copy function should/could also copy the
appropriate BLOB data out of the old BLOB file into the new BLOB file
somewhere and re-point the new record's pointer to that new place in that
BLOB file?

I personally, think this is a question too big to settle without a lot of
discussion and suggestion from everyone. It might be that a consensus of
best compromise is all we are going to
get. It might also be that all this is supposed to work invisibily and
already does, and there is just a small bug somewhere. It may be that it
does work and where doing something wrong.


All I know is it hurts my brain to think about the ramifications and
possible disastrous problems this type of thing could cause. I had always
hoped that the MEMO feature coudl be added in filePro as just that, a MEMO
thing only... specific to MEMO's with all that this entails. By including
BLOB (Binary Large OBject) files in the mix, it complicated everything into
another dimension. The complexity of things now and the unwieldly-ness of it
all is hard to get one's mind around.   My thought was that simply holding a
URL pointer to a BLOB of any kind, inside a filePro field would be a good
solution to needing this ability. You could point to jpeg's, bmp's, avi's,
wav's, etc., and maintain real ease of portability between filePro files.
The locations change, you change the locations. Actually storing the ENTIRE
BLOB file inside a file to be maintained by filePro, and do it for anynumber
of fields on any number of records  is a staggering and daunting challenge,
which I have never seen the benefit of doing. Just maintaning accurate key
and index files is the only job I think filePro should take on, leaving the
rest for everyone else. BLOB's are one thing, MEMO's are another and I think
they should have been treated vastly differently. Okay, another seprate file
for the MEMO's, that might be okay... and also I think limiting filePro to
one good/reliable MEMO field per record would be okay, too. This would
probably frost many people, but I bet the majority would rather have that
than unlimited BLOB/MEMO's which have always seemed to be problematic.

By the way, I do understand that maintaining a BLOB file with BLOB data is
very similar to maintaining one with all MEMOS in it... but it, and maybe
this is the rationale for combining the functionality. It is the storing of
large files period, that I think would have been done better with URL
pointers.

Printing the MEMOS is so complicated now by the fact that there might be
more than one of them on any record, is by the way, why I thought limiting
it to one, might help get this feature to the troops faster. If not, not,
but keeping it the way it is, without being able to print more than one page
of the MEMO keeps them pretty unusable for us.

--
John Esak
Visit The FilePro Room www.tinyurl.com/97y9u 24/7

Author of:
The filePro Survivor Series
Video training for filePro on CD
See samples at: www.valar.com/training