Wouldn't it be safer to first use SyncLock and then test oApp.lInitialize ? If not, I see a possible race condition

            SyncLock oApp.oObjectLock
                  If Not oApp.lInitialize Then
                        If Not LoadDataDictionary() Then
                            Return False
                        End If

>You're welcome! =0)
>
>~~Bonnie
>
>
>
>>>Yes, that *is* what I meant by the double-check locking pattern (by checking first, you only get the lock if you need to) .... however, it seems to me that if you implement this pattern, then there's no reason that you even need to check both oApp.lFirstHit and oApp.lInitialize, is there? I mean, you're initializing only on the FirstHit anyway, so I would think you could simplify this to just the following:
>>>
>>>

>>>            If Not oApp.lInitialize Then
>>>                SyncLock oApp.oObjectLock
>>>                    If Not oApp.lInitialize Then
>>>                        If Not LoadDataDictionary() Then
>>>                            Return False
>>>                        End If
>>>

>>>
>>>And then you could totally remove the lFirstHit property from oApp (unless you're using it for something else also).
>>
>>I had to do some testing to see if that was the equivalent use and yes. So, I got rid of that property. Your schema is the one I have right now. I do have additional similar processes when the data dictionary changes along the route, but at first, it is exactly like that. I am doing some more testing tonight but it sounds good.
>>
>>Thanks