By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,225 Members | 2,172 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,225 IT Pros & Developers. It's quick & easy.

VB variance from machine to machine

P: n/a
I wrote a VB program on my Windows XP machine. It does multi table queries,
you can add/delete and edit records, it all worked very beautifully. I was
very careful to validate data, and on my machine it works very well.

I compiled it, and sent the executable, which works fine on my machine, to a
business elsewhere.

They also have a Windows XP machine. When they run my executable, using the
same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces. When he makes a change to any
record, that change is copied to every record.
Has anyone seen any strange things happening when moving code from machine
to machine?
Adrian
Jul 17 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a

"Adrian Parker" <ad***********@NOSPAMsympatico.ca> wrote in message
news:L_******************@news20.bellglobal.com...
They also have a Windows XP machine. When they run my executable, using the same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces.


Your text fields are most likely set to a "data source". The data source
points to the database and data. So the database might be pointing to your
local drive and directory which won't exist on your customer PC (unless you
reproduce the exact environment).

This of course can be done programatically, for example:

Data1.DatabaseName = "c:\whereever\whatdb.md"
Data1.RecordSource = "Select * from ..whatever"
Data1.Refresh

Jul 17 '05 #2

P: n/a

"Adrian Parker" <ad***********@NOSPAMsympatico.ca> skrev i en meddelelse
news:L_******************@news20.bellglobal.com...
I wrote a VB program on my Windows XP machine. It does multi table queries, you can add/delete and edit records, it all worked very beautifully. I was very careful to validate data, and on my machine it works very well.

I compiled it, and sent the executable, which works fine on my machine, to a business elsewhere.

They also have a Windows XP machine. When they run my executable, using the same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces. When he makes a change to any
record, that change is copied to every record.
Maybe a stupid question , but are you sure you've made the path to mdb
files to "app.path" and not a static path that it was on your machine ??

It seems like blank spaces in all your text boxes on init, is a database
not found !!



Has anyone seen any strange things happening when moving code from machine
to machine?
Adrian

Jul 17 '05 #3

P: n/a

"Steen Gellett" <He*******@NoSpam.Net> wrote in message
news:40***********************@dread16.news.tele.d k...

"Adrian Parker" <ad***********@NOSPAMsympatico.ca> skrev i en meddelelse
news:L_******************@news20.bellglobal.com...
I wrote a VB program on my Windows XP machine. It does multi table queries,
you can add/delete and edit records, it all worked very beautifully. I

was
very careful to validate data, and on my machine it works very well.

I compiled it, and sent the executable, which works fine on my machine,

to a
business elsewhere.

They also have a Windows XP machine. When they run my executable, using

the
same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces. When he makes a change to any
record, that change is copied to every record.


Maybe a stupid question , but are you sure you've made the path to mdb
files to "app.path" and not a static path that it was on your machine ??


Yes. His machine opens the database, because the data in one of his
non-bound controls (a combo box) is properly receiving data from a query,
and is being populated properly.
Adrian
Jul 17 '05 #4

P: n/a

"Raoul Watson" <Wa*****@IntelligenCIA.com> wrote in message
news:17*****************@nwrdny01.gnilink.net...

"Adrian Parker" <ad***********@NOSPAMsympatico.ca> wrote in message
news:L_******************@news20.bellglobal.com...
They also have a Windows XP machine. When they run my executable, using the
same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces.


Your text fields are most likely set to a "data source". The data source
points to the database and data. So the database might be pointing to your
local drive and directory which won't exist on your customer PC (unless

you reproduce the exact environment).

This of course can be done programatically, for example:

Data1.DatabaseName = "c:\whereever\whatdb.md"
Data1.RecordSource = "Select * from ..whatever"
Data1.Refresh


I used a relative path. Or, in other words, I left the directory prefix off
and just quoted the filename. Hi DB is in the same folder as is the EXE,
which is correct.

It's finding the database, because some of the data is displayed properly.
I have a combo box which is filled using an sql query.

Adrian
Jul 17 '05 #5

P: n/a
Adrian Parker wrote:
I wrote a VB program on my Windows XP machine. It does multi table queries,
you can add/delete and edit records, it all worked very beautifully. I was
very careful to validate data, and on my machine it works very well.

I compiled it, and sent the executable, which works fine on my machine, to a
business elsewhere.

They also have a Windows XP machine. When they run my executable, using the
same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces. When he makes a change to any
record, that change is copied to every record.
Has anyone seen any strange things happening when moving code from machine
to machine?
Adrian


Usually, when I do database programming, and the fields are blank, its
because MDAC isn't installed on the target machine, or some other
databasing component (depending on what you're using to connect to the
data file).

The best thing to do is use the Package & Deployment Wizard to create an
installation for your program, then install it on the target machine.
This will ensure the target machine has all the needed ActiveX Controls
that VB so heavily relies on.

It usuallt works without a hitch, or installation on the development
machine because by installing the development enviroment, that also
installs all the needed controls, etc.

Hope this helps

g
z
Jul 17 '05 #6

P: n/a

"Gemini" <sp**@nospam.org> wrote in message
news:66***************************@dcanet.allthene wsgroups.com...
Adrian Parker wrote:
I wrote a VB program on my Windows XP machine. It does multi table queries, you can add/delete and edit records, it all worked very beautifully. I was very careful to validate data, and on my machine it works very well.

I compiled it, and sent the executable, which works fine on my machine, to a business elsewhere.

They also have a Windows XP machine. When they run my executable, using the same database I use, the program opens and sets all textboxes (which are
linked to table fields) to blank spaces. When he makes a change to any
record, that change is copied to every record.
Has anyone seen any strange things happening when moving code from machine to machine?
Adrian

Usually, when I do database programming, and the fields are blank, its
because MDAC isn't installed on the target machine, or some other
databasing component (depending on what you're using to connect to the
data file).


That'll be it!

Thanks.

He won't have MDAC installed, he'd have no reason too.

The best thing to do is use the Package & Deployment Wizard to create an
installation for your program, then install it on the target machine.
This will ensure the target machine has all the needed ActiveX Controls
that VB so heavily relies on.

It usuallt works without a hitch, or installation on the development
machine because by installing the development enviroment, that also
installs all the needed controls, etc.

Hope this helps


Very much, thank you.

Adrian
Jul 17 '05 #7

P: n/a

"Gemini" <sp**@nospam.org> wrote in message
news:66***************************@dcanet.allthene wsgroups.com...
Adrian Parker wrote:

Usually, when I do database programming, and the fields are blank, its
because MDAC isn't installed on the target machine, or some other
databasing component (depending on what you're using to connect to the
data file).

The best thing to do is use the Package & Deployment Wizard


Where do you find this Package & Development Wizard? My school has VB 6
licenses, but I do not see this utility anywhere in VB.

Adrian
Jul 17 '05 #8

P: n/a
Nevermind, found it.

It's output is really messy. Makes a LOT of files, a new directory, etc.
Adrian

"Adrian Parker" <ad***********@NOSPAMsympatico.ca> wrote in message
news:Nv********************@news20.bellglobal.com. ..

"Gemini" <sp**@nospam.org> wrote in message
news:66***************************@dcanet.allthene wsgroups.com...
Adrian Parker wrote:

Usually, when I do database programming, and the fields are blank, its
because MDAC isn't installed on the target machine, or some other
databasing component (depending on what you're using to connect to the
data file).

The best thing to do is use the Package & Deployment Wizard


Where do you find this Package & Development Wizard? My school has VB 6
licenses, but I do not see this utility anywhere in VB.

Adrian

Jul 17 '05 #9

P: n/a
Adrian Parker wrote:
Nevermind, found it.

It's output is really messy. Makes a LOT of files, a new directory, etc.
Adrian


<snip>

Right, but the core of those (only a couple of files) is all thats
needed. The ones in SUPPORT aren't needed for distribution. I think you
just need the setup.exe, setup.lst and the CAB file and you're good to
go. The files in the SUPPORT directory basically represent whats in the
CAB file.

Also, you can d/l the updated Visual Studio Installer. It has a great
script for creating VB Installations.

Scott Zielinski
Jul 17 '05 #10

P: n/a

"Gemini" <sp**@nospam.org> wrote in message
news:e6**************************@dcanet.allthenew sgroups.com...
Adrian Parker wrote:
Nevermind, found it.

It's output is really messy. Makes a LOT of files, a new directory,
etc.

Right, but the core of those (only a couple of files) is all thats
needed. The ones in SUPPORT aren't needed for distribution. I think you
just need the setup.exe, setup.lst and the CAB file and you're good to
go. The files in the SUPPORT directory basically represent whats in the
CAB file.

Also, you can d/l the updated Visual Studio Installer. It has a great
script for creating VB Installations.


How does one make a single file EXE which installs everything needed?
Also, when you create a package on Windows 2000, then install on XP, it
replaces system files. Then XP complains that your system might be
unstable.

Adrian
Jul 17 '05 #11

P: n/a
Adrian Parker wrote:
"Gemini" <sp**@nospam.org> wrote in message
news:e6**************************@dcanet.allthenew sgroups.com...
Adrian Parker wrote:

Nevermind, found it.

It's output is really messy. Makes a LOT of files, a new directory,


etc.
Right, but the core of those (only a couple of files) is all thats
needed. The ones in SUPPORT aren't needed for distribution. I think you
just need the setup.exe, setup.lst and the CAB file and you're good to
go. The files in the SUPPORT directory basically represent whats in the
CAB file.

Also, you can d/l the updated Visual Studio Installer. It has a great
script for creating VB Installations.

How does one make a single file EXE which installs everything needed?
Also, when you create a package on Windows 2000, then install on XP, it
replaces system files. Then XP complains that your system might be
unstable.

Adrian


You could package those couple of files into a self-extracting archive.
Like WinZip, or something similar.

Also, the Vis Stud Inst creates a single .msi file (much like an .exe
file, but requires the Windows Installer to be on the system) Most
Win2k+ computers have it built in.

Scott C. Zielinski
Jul 17 '05 #12

P: n/a

"Gemini" <sp**@nospam.org> wrote in message
news:e2**************************@dcanet.allthenew sgroups.com...
Adrian Parker wrote:
"Gemini" <sp**@nospam.org> wrote in message
news:e6**************************@dcanet.allthenew sgroups.com...
Adrian Parker wrote:
Also, when you create a package on Windows 2000, then install on XP, it
replaces system files. Then XP complains that your system might be
unstable.

You could package those couple of files into a self-extracting archive.
Like WinZip, or something similar.

Also, the Vis Stud Inst creates a single .msi file (much like an .exe
file, but requires the Windows Installer to be on the system) Most
Win2k+ computers have it built in.


When I make a package on Windows 2000, then use the installer on XP, it
replaces required Windows librairies. The system then complains it may be
unstable. Is there any way to avoid this?
Adrian
Jul 17 '05 #13

P: n/a
Adrian Parker wrote:
"Gemini" <sp**@nospam.org> wrote in message
news:e2**************************@dcanet.allthenew sgroups.com...
Adrian Parker wrote:

"Gemini" <sp**@nospam.org> wrote in message
news:e6**************************@dcanet.allthe newsgroups.com...
Adrian Parker wrote:
Also, when you create a package on Windows 2000, then install on XP, it
replaces system files. Then XP complains that your system might be
unstable.

You could package those couple of files into a self-extracting archive.
Like WinZip, or something similar.

Also, the Vis Stud Inst creates a single .msi file (much like an .exe
file, but requires the Windows Installer to be on the system) Most
Win2k+ computers have it built in.

When I make a package on Windows 2000, then use the installer on XP, it
replaces required Windows librairies. The system then complains it may be
unstable. Is there any way to avoid this?
Adrian

Don't know too much about the imstaller and WinXP

g
z
Jul 17 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.