You may handle it the same way as described (in BeforeOpenTables event). The only difference for free tables (if you have them) is that you should reset Cursor.CursorSource properties.

>I have been following this tread with great interest! I am a 2.6 "coder" trying to make the transition to VFP5, I'm liking what I see in OOP, but am having a problem dealing with my current concept for handling "tables". All my existing files are scattered across a Novell server based on users authoriztions to make sure users don't start poking around where they don't belong.
>
>I have 3 different "companies" that run the same programs, but hit different data files (ie. 3 AP's, 3 AR's etc..) In my 2.6 "toolbox", I have a function that I wrote that looks up the correct location for table, based on the user, system and company.
>
>Is there a way to handling this in the DE such that I will not lose the benefits of the Visual DataEnvironment and still maintain the flexiblity that I have had in the past???
>
>Norm
>
>
>> If DE.AutoOpenTables=.T. then DE.BeforeOpenTables event is appropriate place.
>> If DE.AutoOpenTables=.F. and you fire DE.OpenTables programmatically from
>> some form's event (init ?) then you may fire the same code right before it.
>> Also, you may still put the code to BeforeOpenTables event and just call:
>> This.DataEnvironment.BeforeOpenTables()
>>
>>>Hi Ed,
>>>I am working on a project where their are two copies of the DBC I want to
>>>use. To use the DBC (and associated files) in the alternate location, I
>>>turn auto open off, and manually open the DBC and files. In this case,
>>>DE.BeforeOpenTables does not fire, so I ended up moving the SetAll() code
>>>into the init or the openfiles events aswell. Is there a better way to do
>>>this? ie. How do I change the path for the DE, before the DE is opened, when
>>>it seems like the DE is the very first thing opened in a form? Thanks.
>>>
>>>Daniel
>>>
>>>
>>>>Usually, it's recommended to reset these paths in DE.BeforeOpeTables event(s)
>>>>Thisform.SetAll("Database",cDbcpathname,"Cursor")It works straightforward
>>>>if all DE.cursors are dbc-ed tables. If some cursors associated with free
>>>>tables, then this code should be adjusted.
>>>>
>>>>OK, Jack, but what *do* you do about the hardcoded paths in the DBC????