hi Bonnie,

Didn't say you made it up

Just thought that in case something can reset oApp.lInitialize - for whatever reason - the first test may think it's initialized and when it executes the next line it isn't anymore

ie, as long as nothing resets oApp.lInitialize, you are right. But wouldn't a static initializer be more clear in this case ?

private/public static Dictionary TheDictionary = LoadDataDictionary() ; // as long as LoadDataDictionary()  returns a dictionary

__
>The point of this double-check locking pattern is two-fold:
>
>1) To avoid taking the expensive lock if it's not necessary (by the first check of oApp.lInitialize).
>2) Once you get the lock, you check oApp.lInitialize a second time before proceeding, because it could have become true in between the time you first checked it and after you got the lock.
>
>This is a well-known and reommended pattern ... I didn't make it up. <g>
>
>~~Bonnie
>
>
>
>>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