I suspect timing. There is as you know a lot going on under the
hood. My personal experience with "intermittent" errors is to shout
Timing!!!

It may of course be a knee jerk... :-)

Try putting som DoEvent statements in your code  so that some processes
definately finish before others start.

In multi thread environments it's normal to check and see if a
particular thread has finished before continuing. Maybe you meed to
incorparate something like that.

Are you using a "fast" computer? Does the code run  ok on a slower
computer?.. ie an older one :-)

Windows typically uses write after caching.. Is the cache getting
written away before a different procedure  needs the data?

My program is not itself multi-threading,
so VBA / Windows should take care of any timing issues (I can't put a
DoEvents on every other line...) I'm going to put it down as a bug
in VBA.

Have you posted the code  that you are using to access your file? I don't recall
seeing it.

Some file I/O statements run  asynchronously and you have to specifically check
for completion.

here is an example of the code  I am using. The 'Bad Record
Length' error  occurs here (on the Get... line) and elsewhere in my
program, for this and some other user-defined  data types. The
OpenFile function just opens the record  file for random access as
read-only and returns the file number. The line that includes  the
OpenFile function is equivalent to

intFileUsr = FreeFile
Open <recordfile> For Random Access Read As intFileUsr Len = Len
(usrThis)


As I mentioned previously I can force a restructuring of the data
type by removing reference  to an element, attempting to run  some code
that includes this element, then reinstating the element. Everything
is fine  again then.

Public Type UsrType
LoginID As String * 5
Name As String * 20
SiteID As Byte
DeptID As Integer
Active As Boolean
Password As String * 10
PasswordSetDate As Long
HalfDayHolEnt As Byte
Perm(1 To 20) As Boolean
End Type

Public Sub USR_List(cntThis As MSForms.Control, Optional
blnIncInactive As Boolean)

'Display a list of users in a list or combobox

Dim intFileUsr As Integer
Dim usrThis As UsrType

cntThis.Clear

intFileUsr = OpenFile(FileName(PATH_STATIC, FILETITLE_USR,
FILEEXT_USR), Len(usrThis), False, False)

Do
Get intFileUsr, , usrThis
If EOF(intFileUsr) Then Exit Do
If usrThis.Active Or blnIncInactive Then cntThis.AddItem
usrThis.LoginID
Loop

Close intFileUsr

End Sub

No mention in the help of the get being asynchronous, and the code  looks
straightforward enough.

I do have a concern with your Perm(1 To 20) ...

The help for "get" talks about dynamic arrays and gives as example:

Dim MyArray(1 To 5,1 To 10) As Integer

I don't know if it treats such definitions as dynamic, even though they're not.
The gist of it is that you need to allow extra bytes for descriptors.

Are you in a position to try this with a more "traditional" array dimension to
see if it helps?

The only other thing I found in a quick Google trawl was a suggestion to use
LenB() instead of Len() to get the length  of UsrType.

Odd indeed that forcing a bad  compile is enough to fix the problem for a while.
Maybe there is a bug.

Quite sure it isn't a problem with arrays as I also get the error
(again intermittently) with this data  type:

Public Type TypeTRA
TypeID As Byte
Ref As String * 8
Date As Date
StockCode As String * 20
Qty As Integer
LocFrom As String * 9
LocTo As String * 9
End Type

The value returned by Len is not a problem, it is the same whether
the code  works or not.

I'm inclined to believe that there is some internal VBA bug  that
corrupts the data type structure in some way.