Our application has several tables in it where records with a null @id will occasionally turn up. This causes major problems with some of our processes. The odd thing is, if I do a 'SELECT {TABLE} BY @ID' and then 'EDIT {TABLE}' sometimes the null record will be the first one, and sometimes it won't show up at all. The only reliable way I have of detecting and deleting the records is programmatically. Now, I don't have a problem with that, and I've written a program that scans several of the tables, deletes a null record if it's found and then does an index flush on that table.

I guess my question really is, where are theses null records coming from. We've looked at thousands of lines of code that deal with these tables, and can't really find any sort of loophole where we would be writing to the table with a null id.

Any ideas or advice would be greatly appreciated.

Matt Sorrell

M.G.A., Inc.

Matt,

Rest assured that null key records are not a common artefact of regular AREV processing. There is probably a collector window or

some other batch process which is causing the problem.

You may be able to trap the offending process using an audit MFS on the file where these record appear. You can write the program stack to the log file if the key is null to identify the culprit routine.

Hope this helps,

Steve

Steve,

I appreciate the information. Now, however, I must show my ignorance. I have never messed with MFS's before. I barely know what you are talking about, and would have no clue as to how to write an audit MFS attached to one of my tables.

Any leads or resources you could point me to would be appreciated.

TIA,

Matt Sorrell

M.G.A., Inc.

Sounds like a relational index problem to me. Even if you clean out the target record the source record with the relational field will keep writing it back every time you make a change to it. A quick fix would be to find the find the target record, then go to the target field and delete it. Best and safest method however, would be to rebuild the relational index.

Sorry, I meant to say find the SOURCE record and SOURCE field and then delete the data inside the SOURCE field. That will stop the target record from being recreated. Still just rebuild your index for a more secure fix. You may have other bad source records in the table.

Here's a copy of a prog which will do what you want. You'll have to add the mfs to the file and create the AUDIT_File. You can do that by editing the Revmedia record for the file you want to audit. There's several Knoweldge Base pages regarding MFSs which will be useful.

SUBROUTINE NULL_CHECK_MFS(CODE,BFS,HANDLE,RECID,FMC,RECORD,STATUS)

$INSERT INCLUDE,FILE.SYSTEM.ONGOSUB

RETURN

INSTALL:

STATUS=1

RETURN

FLUSH:

CREATE.MEDIA:

OPEN.MEDIA:

READ.MEDIA:

WRITE.MEDIA:

LOCK.SEMAPHORE:

UNLOCK.SEMAPHORE:

SET.USER.SEMAPHORE:

FLUSH.CACHE:

GROUP.NUMBER:

RECORD.COUNT:

RESERVED:

CREATE.FILE:

RENAME.FILE:

MOVE.FILE:

DELETE.FILE:

OPEN.FILE:

CLEARFILE:

SELECT:

READNEXT:

CLEARSELECT:

READ.RECORD:

READO.RECORD:

OPEN.FILES:

DEBUG

OMNI.SCRIPT:

CLOSE.MEDIA:

REMAKE.FILE:

CREATE.INDEX:

DELETE.INDEX:

UPDATE.INDEX:

SELECT.INDEX:

READNEXT.INDEX:

FS      =DELETE(BFS,1,1,1)

NEXTFS  =FS

CALL @NEXTFS(CODE, FS, HANDLE, RECID, FMC, RECORD, STATUS)

RETURN

WRITE.RECORD:

if len(RecId)=0 then

  open "AUDIT_FILE" to AuditFile then

    AuditRec =date()

    AuditRec := @fm: time()

    AuditRec := @fm: @sentence

    AuditRec := @fm: @username

    write AuditRec to AuditFile,RecId

  end

end

DELETE.RECORD:

LOCK.RECORD:

UNLOCK.RECORD:

UNLOCK.ALL:

  FS    =DELETE(BFS,1,1,1)

  NEXTFS=FS

  CALL @NEXTFS(CODE, FS, HANDLE, REC.ID, FMC, RECORD, STATUS)

RETURN

View this thread on the forum...