Solved

Package & Deployment

Posted on 2000-02-14
10
267 Views
Last Modified: 2013-11-23
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????
0
Comment
Question by:DrJax
10 Comments
 

Expert Comment

by:kartono
ID: 2521124
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
0
 
LVL 7

Accepted Solution

by:
kamall earned 130 total points
ID: 2521140
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).
Regards.
0
 
LVL 7

Expert Comment

by:kamall
ID: 2521147
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.
0
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.

 
LVL 1

Expert Comment

by:brandonb
ID: 2521178
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.
0
 
LVL 7

Expert Comment

by:kamall
ID: 2521201
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.
0
 
LVL 7

Expert Comment

by:kamall
ID: 2521231
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.
0
 
LVL 1

Expert Comment

by:brandonb
ID: 2521274
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.
0
 

Author Comment

by:DrJax
ID: 2524363
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.


0
 
LVL 1

Expert Comment

by:brandonb
ID: 2524482
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.
0
 
LVL 7

Expert Comment

by:kamall
ID: 2525371
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.

0

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.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When trying to find the cause of a problem in VBA or VB6 it's often valuable to know what procedures were executed prior to the error. You can use the Call Stack for that but it is often inadequate because it may show procedures you aren't intereste…
Introduction Raise your hands if you were as upset with FireMonkey as I was when I discovered that there was no TListview.  I use TListView in almost all of my applications I've written, and I was not going to compromise by resorting to TStringGrid…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

792 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question