Home/ Questions/Q 3281156
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T19:47:05+00:00

My application reads an Access database file that can be updated at runtime by

  • 0

My application reads an Access database file that can be updated at runtime by downloading a replacement MDB file (with the same schema) and overwriting the existing file. This is all well and good during development, but it breaks during deployment.

The main problem is that the connection string for the data adapters is 

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\ModelDatabase.mdb"

in which the |DataDirectory| token often equals the application root directory. Vista doesn’t like it when I download a new file and try to delete the existing MDB file — an UnauthorizedAccessException is thrown, and rightfully so, because I shouldn’t be messing with files in the application root.

Instead, I should be downloading and updating files in an application data directory, such as Application.CommonAppDataPath.

So, I am faced with two possible solutions (in order of preference):

  1. Somehow redefine that |DataDirectory| token to point to Application.CommonAppDataPath. I’ve tried AppDomain.CurrentDomain.SetData("DataDirectory", Application.CommonAppDataPath) with no luck; the data adapter throws an exception “Invalid value for key ‘data source’.” when it tries to populate a DataSet.

  2. Update the dataset programmatically, populating every table using its specific data adapter, then inserting, updating, and deleting data rows. This seems like an awful pain when a simple file move would suffice.

Is there a way to make solution #1 work, by redefining this magic DataDirectory token? Where is this domain variable defined, anyway?

Or is there a better way to solve this problem?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Gah! I figured it out.

    The solution is, in fact, to call

    AppDomain.CurrentDomain.SetData("DataDirectory", Application.CommonAppDataPath)

    The problem was that the assembly’s company name ended in “Inc.”, so one of the directory names in the app data path ended with a period character. It appears that data connection did not like this behavior.

    • 0