We always use UNC convention as opposed to network mappings, since we can't rely on all our users' network mappings to be the same. I can tell you that, at runtime, if the user can't "see" the network mapping in your MetaDBC, your DE won't be able to instantiate its cursor object(s) -- views -- and then GetDataAccessObject() will fail... so maybe this is your problem?

I don't know how you have your MetaDBC set up, but maybe you could temporarily use the MM demo's MetaDBC to fire up your app and see if the user/usergroups forms work?

Short of that, I would step through the instantiation of one of the BizObjs on these forms, especially where it's loading a DE. It can be tedious, but it should provide a "D'oh!" moment -- and then you'll have something only a fun issue like this can provide... experience!!

---J

>Yes, I ONLY use the builders. Yes, I have compared them and they "look" the same, but obviously are not acting the same!
>
>Is there any restriction in the framework regarding path names, etc. in the metadbc.dbf table? I've mapped a network drive to a G: logical drive designation. Then I add the data sub-directory like this: G:\DATA\My.DBC. I can't see why this would cause a problem?
>
>My client machines contain all the same files in their application directory that are in the application directory of the network server location. The EXEs, Free tables, etc. This seems like it would be ok.
>
>And, the data environment that is causing a problem in client/server mode works perfectly fine in local mode? This is not the user group issue, but another issue. Beats me??? I'm missing a point here I believe.
>
>Just doesn't make any sense to me, Jason.