Hi Jason,

I didn't find your post dense at all, and no, the app didn't just start working.

I went through all the metadbc's and INI's at the workstations and updated any reference to ytimeclock.dbc to the full path (including drive letter: f:\Program Files\yTimeClock\data\yTimeClock.dbc) and made sure that the reference in the ini's pointed to the same dbc, and recompiled the app just in case.

Alex

>Alex,
>
>We do all those things! None of our dbcs are in the dev path's data folder, and none share the application name.
>
>We only use the MetaDBC (as opposed to the .Ini file) to track dbc location. Any time we move dbcs, and we have done so multiple times, the only concerns are updating the MetaDBC and making sure appropriate network rights are bestowed upon the corresponding users.
>
>I guess I'm dense-r than usual today, but I couldn't tell from your last post what you finally found the problem to be. Please tell me it didn't just suddenly decide to start working this week!
>---J
>
>
>>Hi Jason,
>>
>>I moved everything to the F: drive and the mappings all point to the right drive (f:).
>>
>>I also made sure that the references both in the .ini file and the metadbc table point to f:\program files\ytimeclock\data\yTimeClock.dbc.
>>
>>The system seems to be working fine now.
>>
>>I will contact Kevin directly to write a short document about detailed requirements for databases located in directories other than the _applicationPath\data directory, especially when the name of the database is NOT the same as the name of the application, as I'm really not sure about how the .ini/registry and metadbc table relate to one-another.
>>
>>In addition to that I have had the app complain once about not being able to find the errorlog.dbf table.
>>
>>Thanks to you and Paul for all your help!
>>
>>Alex