<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18876"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>You know, it's funny, I was going to suggest that you might be doing
the memo and filling into different files... was there a lookup involved... but
I just didn't and suggested the other. I did immediately think the duh
thing though, because I have done the very same thing.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>Don't feel bad, years ago... I remember calling in to Ken or somebody
and saying "Oh my God! filePro has just removed all the data in field 44 of my
most important file!!!! There isn't one bit of data on any record in field
44!!!". and of course followed with the obligatory, "I've done nothing to this
stuff for 10 years!!!" It took me a few panicked minutes to figure
out what happened.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>Hmmm, should I leave this for a brain teaser or just ell you how dumb
I was. I'm sure many have gotten it already. A clue... For some insane reason I
had put a password on the file a couple days earlier.. .it was our payroll
employee file. The field that had been cleared was the Salary field.
Those who haven't gotten it yet, probably have now. It turned out that I had
forgotten that when there is a file password, and you access that file with
*clerk, filePro will not show you the contents of any field on the IUA Browse if
you have not *already* seen that field on some screen. This is actually a
great protection for just such things. You want someone to be able to enter
hours for employees but you don't want this person to see the actual Salary or
Hourly Wage fields. So, you don't put them on any screen they can see.
Hence, when you display those fields on the browse, they are completely
empty. If you don't think seeing an entire field completely blank on every
record will stop your heart... well, it will. :-) I had been
checking this field in IUA instead of just doing a report or some selset that
would have brought me to particular records based on that field... There were a
hundred things I could have done... but all I did do was keep looking at the
empty browse and jumping to the erroneous conclusion that *filePro* that
)(*&^ program screwed my data and me. :-) Funny, how that is just
about everyone's first reaction ... filePro did it! :-)
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>Happily, except for that horrible period just after 4.5 when DKNF
beat us all up for awhile, filePro is 99.9% usually not the cause of bad
data. In the past 15 years or so I have come to never think of filePro
being the culprit first... and that has been a good time saver. The problem is
usually pilot error on my part.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><FONT size=2 face=Arial></FONT> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>John</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>P.S. - Okay, so DKNF was not a short "period", but more like a half a
decade and 2 version levels... :-) But still... At least we have the
fastest indexes around. So the time squashing that group of bugs was
finally well worth it.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial>
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=906083218-24032010><FONT size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><FONT size=2 face=Arial></FONT> </DIV>
<DIV dir=ltr align=left><FONT size=2 face=Arial></FONT> </DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr align=left><FONT size=2 face=Tahoma><B>From:</B> Boaz Bezborodko
[mailto:boaz@mirrotek.com] <BR><B>Sent:</B> Wednesday, March 24, 2010 2:28
PM<BR><B>To:</B> john@valar.com<BR><B>Subject:</B> Re: Large field not getting
recorded<BR></FONT><BR></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV></DIV>I got the solution . See my reply to Ken. <BR><BR>I
feel like an idiot.<BR><BR>John Esak wrote:
<BLOCKQUOTE cite=mid:201003241819.o2OIJEAL065392@admin114.securesites.net
type="cite"><PRE wrap="">There used to be a situation where you would do:
Memo 33 edit
Put some stuff in the memo and then leave the memo field. When looking
immediately in t the memo was
empty. Now, possibly something odd is happening with memo 33 import and
it's clearing its designated field? The fix for the other was to do a
generic WRITE on the line immediately after the memo 33 edit so the current
record would be written. This cured the problem, and you could now
immediately see the data just entered. So, heck, why not try putting a
generic WRITE immediately after the memo ### import line.
John
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:filepro-list-bounces+john=valar.com@lists.celestial.com">filepro-list-bounces+john=valar.com@lists.celestial.com</A>
[<A class=moz-txt-link-freetext href="mailto:filepro-list-bounces+john=valar.com@lists.celestial.co">mailto:filepro-list-bounces+john=valar.com@lists.celestial.co</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->m] On Behalf Of Boaz Bezborodko
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Sent: Wednesday, March 24, 2010 1:04 PM
To: <A class=moz-txt-link-abbreviated href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</A>
Subject: Large field not getting recorded
A few days ago I wrote about having problems loading a file
into MEMO.
Instead of using MEMO I was told about WORDWRAP. But I am
now getting a
different problem.
I changed the memo field from a 16,memo to a 148,*. But when
the record
is being recorded 201 is getting cleared. When I go through
the table
using DEBUG the program is properly loading 201, but when I
look at it
again afterwards, 201 is blank.
I thought that maybe this was a problem or bug due to switching the
field from memo to *. SO I tried creating a new field also
with 148,*
and loading both with the same data. In both cases the fields are
loaded with the data during an import, but are empty when I
look at them
later.
At no point do I do anything with these fields other than when I load
them with the data.
What could be causing this? It's really holding me up on my
programming
since my code is working all except for this.
Boaz
_______________________________________________
Filepro-list mailing list
<A class=moz-txt-link-abbreviated href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</A>
<A class=moz-txt-link-freetext href="http://mailman.celestial.com/mailman/listinfo/filepro-list">http://mailman.celestial.com/mailman/listinfo/filepro-list</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>