I came up with a different solution and I thought I'd pass the solution on to everyone. I put nothing in the DE, set the AutoOpenTables=.F., put the code for opening the correct table in the OpenTables method and in the Init method of the DE added the line THIS.OpenTables.


>>>>I have a form that is used for each users timesheet entries. The problem that I have though is that each user has their own DBF. (i.e. \DATA\THSHT\%user name%\TMSHT.DBF). Each user can only access their own TMSHT.DBF. My question is this. I don't know which DBF needs to be opened until the form is run so what is the best way to handle this in the DE of the form?
>>>
>>>Is there a reason for this design instead of having one table for all users? What you are attempting is sort of a distorted normalization, but doing it by the book might avoid these problems. The way I track this stuff is with two tables: one user data table with basic user info (username, password, priveleges setup date, etc) and one with login history for all members (member_id, activity name, datetime). There is really no need for separate tables, unless of course there are some file privelege issues or other special security considerations. HTH
>>
>>I'm stuck in a situation where I have to deal with someone elses data design. I have no idea why the person before me set it up like this when it should be, IMHO, one file with an extra field for Employee Number. This point aside, there are quite a few programs currently using these files so I'm stuck dealing with things as is. Any ideas?
>
>Well, Edwards code sounds like a sound suggestion, but if it doesn't work or you don't like it, you could:
>Put nothing in the DE in design mode.
>After getting the username,
>tablename = "table" + alltrim(thisform.username) && or whatever you naming convention is
>use &tablename alias usertable in 0 shared
>
>Then you can base all the rest of the code and controls on usertable.fieldname
>
>Just an idea as to how I might go about it. HTH