APPEND . . . REPLACE is failing to populate fields

[AndrewMozley]

I have a very long running Clipper 5.3 application, and am finding that a sequence of instructions to APPEND a record and populate its fields is sometimes failing.

This application is running on a network of two users.

The sequence of instructions which I am using is :

SELECT mytable
APPEND BLANK
REPLACE Field1 WITH Val1
REPLACE Field2 WITH Val2
. . .

(I realize that I could combine the REPLACE commands)

Usually this works fine, but on about one record in 4,000 over the past two years, although a record is being APPENDed, it is not being populated: there is a blank record in the table. (over the preceding four years, at least, there had not been a problem)

I know that I could (perhaps should) issue a NetErr() call to see whether the APPEND has worked; but that does not seem to be the problem; the record is indeed being appended - it is just not being populated.

Should I perhaps enclose the REPLACE sequence with an IF RLOCK() . . . UNLOCK bracket? The rest of a fairly substantial system has worked happily for over 10 years, and although it may be lazy, I had not thought that there was any danger of multi-user interference between APPEND and REPLACE.

Alternatively, is there a way that I can test whether the REPLACE commands have worked? It might be difficult for me as developer, to check this out, because the code always works for me when I test it! No doubt that is what users are for!

Thanks. Andrew

 

[GriffMG]

Hi

I would tend to use a UDF for the adding of records in a multi user environment:

(just for reference below YES is "Y", NO = "N")

FUNCTION ADD_REC
	PRIVATE MFLG,CONTFLG
	CONTFLG = YES
	MFLG = .F.
	DO WHILE .NOT. MFLG .AND. CONTFLG = YES
		APPEND BLANK
		IF .NOT. NETERR()
			IF LEFT(ALIAS(),3) <> "TMP"
				HDDSAVED = .T.
			ENDIF
			MFLG = .T.
		ELSE
			TONE(100,2)
			TONE(400,2)
			IF CONFIRM("Unable to add Record: Retry ")
				MFLG = .F.
				CONTFLG = YES
			ELSE
				CONTFLG = NO
			ENDIF
		ENDIF
	ENDDO
	RETURN(MFLG)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[JCreamerII]

Sounds to me as if the process is pointing to a different record at the point of the replace command. Is is possible that the process is looking at a different record at the point of the replace? For those times it isn't working cleanly. You could check the RECNO() at the point you append blank, and check the RECNO() after the last REPL has gone thru. This test will let you know this could be the issue.

Jim C.

 

[AndrewMozley]

Thank you Griff and Jim

I will follow your advice Griff and use a UDF to Append. I was also looking at a rather historical Guide to Clipper by Rick Spence who offered much the same advice (which I failed to follow at the time).

I am however not sure that the APPEND is failing - it certainly seems to be creating a blank record and it is almost as if it's the REPLACE instructions which are failing. Can that happen? That is, can a REPLACE instruction set some value which a subsequent NETERR() call will detect?

Jim, I too had wondered whether the wrong record was being updated. I don't think that is the case, since I can scan the table for records with the relevant fields (product code in this case), and am only seeing the half dozen records which I knew were there. But it will cost me nothing to do a test on RECNO() and issue a warning message if I detect a difference, and I will follow your advice there.

Thanks again.

 

[GriffMG]

Hi

I believe I have that very book.

I don't know about replace generating a neterr() I'm afraid.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[LyndonOHRC]

Hi, I suggest, in your UDF, that you also test Val1 and Val2... to make sure they actually have a value at replace time. If they happen to be empty the replace command(s) would still execute and give the results your are witnessing.

Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey