Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 276
  • Last Modified:

Package & Deployment

I'm using VB6.  I've completed my program, compiled it, and run it through the Package & Deployment Wizard.  I was very excited as I loaded my first ever VB program onto another computer.  The setup portion of the program seemed a bit slow, but otherwise, the program loaded perfectly.  I became more excited as the user executed the program on its new platform.  He made it through 27 of the 30 forms in the program without a hitch.  However, on form 28, the program is supposed to add to and update a database.  As the error notice came up, I was sick.  The program ran perfectly, but has the wrong path for the database.  The next form showed a different error, but I believe it's related to the database path also.  Is this fixable?  In the design mode, the database is located in the VB98 directory, for ease of use.  That's exactly where the error message said it wasn't on the other computer, because this guy doesn't have VB at all.  What in the world have I done wrong this time????
1 Solution
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 ?

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).
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.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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.
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.

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.
DrJaxAuthor Commented:
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.
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).

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now