Rocket U2 | UniVerse & UniData

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?

What happens if you wrap the Write in a loop with an On Error and Nap, will it eventually write that entry?

i.e. something like

Done = @False

Loop

    Write REC On FILE.CF, ID  On Error

         Done = @False

         Nap 100

     End Then

          Done = @True

    End

Until Done Do

Repeat

Generally, what you describe is the sort of behaviour if something external to UniVerse is accessing the file periodically - such as an AntiVirus routine that is scanning the file when it is written and preventing UniVerse from updating it whilst it is holding it. I think you said before that you are on Windows, so maybe trace using the SysInternals Process Monitor to watch what is going on.

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?

Brian,

I concur regarding an AV scan as the most likely candidate. noting that if you are synchrionising with a backup or mirror (e.g. cloud backup) then youc an hot the same issue. 

Regards

JJ

What happens if you wrap the Write in a loop with an On Error and Nap, will it eventually write that entry?

i.e. something like

Done = @False

Loop

    Write REC On FILE.CF, ID  On Error

         Done = @False

         Nap 100

     End Then

          Done = @True

    End

Until Done Do

Repeat

Generally, what you describe is the sort of behaviour if something external to UniVerse is accessing the file periodically - such as an AntiVirus routine that is scanning the file when it is written and preventing UniVerse from updating it whilst it is holding it. I think you said before that you are on Windows, so maybe trace using the SysInternals Process Monitor to watch what is going on.

We are seeing UniVerse (v11.3.1) write failures (on Windows 2019 64-bit server) when we repeatedly update a record. Here's the code we use to create this scenario:

OPEN '', 'CF' TO FILE.CF ELSE STOP

ID = 'TEST'

FOR I = 1 TO 1000

READ REC FROM FILE.CF, ID ELSE REC = ''

REC<-1> = I:' Iteration' 

WRITE REC ON FILE.CF, ID

NEXT I

END

The write failures will occur at random passes through the for/next loop.

This particular file is type 19, but we also see failures on hashed files as well.

Is there a UniVerse or Windows tunable setting that would help us out? Any other thoughts?