Package & Deployment

May I ask some questions first before answering..

What is the database you are using ? Access / SQL / anything ?

Then Try to check in your user's computer, does it have the same database path as in your computer ?

thanks

Let me clarify a little bit...
The App.Path will return the name of the directory (on the user machine) where he installed your application. This will be the location of the database that you have included with your package. Thus, you will have no problem wherever the user installs your application.
Regards.

Now that the user's computer has run the setup, it has all of the relevant DLL's installed.  You can go back and correct the database path in the program and create a new exe.  Then, just copy the new exe over the one on the user's computer and everything should work fine.

brandonb,
Do you really see that your approach is practical?????
The best solution is to use the App.Path to get the dir of the application and the database. An alternative approach is to have an INI file with the application, which stores the original path of the database. He will just edit the path string in that file (on the user system) and everything IS DONE!
Regards to all.

Note: If you do not distribute the database with your application, i.e. the DB is already on the user system, then use the alternative approach (the INI file).
BTW, a third solution is to ask the user for the location of the DB, when your application runs for the first time, and save the path in an INI file. You can know that your app is now launched for the first time if you don't find the INI file (under the application dir). If so, you ask the user for the path (whatever it is), create the INI file, and write the path in it. Whenever your application runs again, check for the INI file, read the path of the DB, and do whatever you like.
Regards.

kamall,

At this point, my approach is very practical.  DrJax has an application sitting on someone's desktop that has a serious bug.  My experience has been that there is nothing worse than an installed application with a bug that keeps the user from using the application.  My approach allows DrJax to correct the bug and have the corrected application on the desktop ASAP.  Your approach would probably add a day or more to fixing the application.  The sooner the application is fixed, the happier the user.

That being said, if I were DrJax, I would follow my approach to enable the user to begin using the application immediately.  Then, I would begin redesigning the application to use an INI file (or the registry) as kamall suggested.

So, yes my approach is practical in regard to time and ease of fixing the current design of the application, but in the long run, kamall's solution is really the best although it will take more time to implement.

brandonb: I changed the path for the data control to find the *.mdb file, recompiled, and repackaged. I'm getting the same error.  Somehow, the *.mdb file isn't getting included in the package.  If I manually load the file into the folder of the loaded program, it works.  That doesn't make sense to me.  How do I get the compiler/package & deployment wizard to acknowledge the file and carry it into the program?

kamall: I appreciate your words of wisdom, but I'm afraid I don't understand enough about this to do what you suggest.  Despite the fact that I've worked on this program for one year in my spare time, I don't have a good understanding of registry.  Basically, I've bought several books, worked through trial and error, and eventually found something that worked.  Thanks for the effort and if you still think you can help, I'm anxious to hear your next contribution.

First of all, it sounds like you are not adding the MDB while you are creating the setup package.  One of the forms that pops up in the package and deployment wizard is titled "Package and Deployment Wizard - Included Files."  You need to click "Add..." and add your MDB (and any other files that aren't part of the project, such as INI files).  Later, you will get the "Install Locations" form and there you can specify the directory where you want the MDB to be copied to.  $(AppPath) would copy the MDB into the application directory.  Later today (after I get off work), I can email you a project with an example of reading and writing to an INI file if you post your email address.

DrJax,
In my first comment, I wrote:
>>Just put the database in the same directory where you install your application. This is automatically done by the wizard when you add the database to the setup files.                     In your application, use the App.Path to get the directory where your application is currently installed (where the database is located).

What that means:
When you make your package with package and deployment wizard, you must add the files that are custom files, i.e. that are not included automatically by the wizard, like VB runtime DLLs, other DLLs, OCXs, etc. When you add a custom file (from within the wizard), it will be automatically put in the directory where your application will be installed on the user system. The only exception is when the custom file is system-related file (a DLL, on OCX, a VXD driver, or a SYS file).
So, having added your MDB file to the setup files, it will be put under the same dir of the installation dir (on the user system).
Now..., using the App.Path from within your application, you can find where your application is installed on the user system. Hence, if you write:

MyDBPath = App.Path & "\mydb.mdb"

then MyDBPath is a variable which gives you the full path and name of the DB, where it is located on the user system. Thus, you never need to worry about where the user installs your application since you can always find where the DB is.
One more thing: you must assign this path to the 'DATABASENAME' property of the data control when your form loads at run-time, so the data control knows the correct (new) path of the database. i.e:

Data1.DataBaseName = MyDBPath '(the path retrieved by the variable at run-time)

I think that the issue is clear now (hopefully).
Regards.