Program To Solve Wrong Drive Access Problem

  • Thread starter Thread starter Chrissy Cruiser
  • Start date Start date
C

Chrissy Cruiser

For reasons unbeknownst to moi, one of the freeware programs we are
developing wants to access the A: drive for data and only, of course, does
it do this on my machine. Same version installed on five others, no
problems. It's an employee scheduler/payroll running under WDows using VB
and MS Access and has a calendar GUI.

I am looking for something that would write a script or , hell, I don't
know.
 
Chrissy said:
It's an employee scheduler/payroll running under WDows using VB
and MS Access and has a calendar GUI.
Click to expand...

Does the VB program stand alone from the Access database. If so, how do
you tell VB where the database is?
 
Does the VB program stand alone from the Access database. If so, how do
you tell VB where the database is?
Click to expand...

Yes, right now it is alone shipped with a empty DB and empty Backup DB. It
is told to look in the install directory C\ProgramFiles\Scheduler.

Understand, I am not a programmer but the Idea Gal. It was my idea to take
the financial hit to do a freeware version which is directed, more
specifically, for sports officials who manually keep up their games, fees,
assignments etc. And do it poorly so there is constant bickering over who
got paid for what, who did what etc on the officials end.

The programmer, nice kid, very bright, says he has no clue and I surmised
it must be a setting on my machine since the prog doesn't reproduce this
anywhere else on W2K, Xp or W98. Looked in the Registry, nothing. This
started after the zillionth install/deinstall and a few faulty deinstalls.

I open the program and it immediately spins up the A: drive and when any
other function is called, same thing.
 
Chrissy said:
Yes, right now it is alone shipped with a empty DB and empty Backup DB. It
is told to look in the install directory C\ProgramFiles\Scheduler.

Understand, I am not a programmer but the Idea Gal. It was my idea to take
the financial hit to do a freeware version which is directed, more
specifically, for sports officials who manually keep up their games, fees,
assignments etc. And do it poorly so there is constant bickering over who
got paid for what, who did what etc on the officials end.

The programmer, nice kid, very bright, says he has no clue and I surmised
it must be a setting on my machine since the prog doesn't reproduce this
anywhere else on W2K, Xp or W98. Looked in the Registry, nothing. This
started after the zillionth install/deinstall and a few faulty deinstalls.

I open the program and it immediately spins up the A: drive and when any
other function is called, same thing.
Click to expand...

Computers. Aren't they fantastic. Not being able to debug on the machine
that is manifesting the problem is going to make things tricky.
 
Chrissy Cruiser wrote in said:
For reasons unbeknownst to moi, one of the freeware programs we are
developing wants to access the A: drive for data and only, of course, does
it do this on my machine. Same version installed on five others, no
problems. It's an employee scheduler/payroll running under WDows using VB
and MS Access and has a calendar GUI.
Click to expand...

wild guess, try clear your MRU list...fx w/ MRU-blaster from
<http://www.javacoolsoftware.com/downloads.html>.

All the best,
Bjorn Simonsen
 
1. Maybe the program uses some functions from a dll that is not found in the
program's folder. The Windows will continue to search for it in the
locations from the PATH environment variable.
So check the path variable and, if you find it, remove the a:\ from it.
(Win XP: My Computer -> Properties -> Advanced tab -> Environment Variables
button - System variables)
2. Or can be a similar mechanism of the program to search for data files
etc.
3. Search in registry for "a:". Maybe you will find something related (a
search path of a program etc).
 
Computers. Aren't they fantastic. Not being able to debug on the machine
that is manifesting the problem is going to make things tricky.
Click to expand...

LOL

Tell me about it.
 
1. Maybe the program uses some functions from a dll that is not found in the
program's folder. The Windows will continue to search for it in the
locations from the PATH environment variable.
Click to expand...

The dlls are in the System folder, nice and neat.
So check the path variable and, if you find it, remove the a:\ from it.
(Win XP: My Computer -> Properties -> Advanced tab -> Environment Variables
button - System variables)
Click to expand...

Good. Thanks.
2. Or can be a similar mechanism of the program to search for data files
etc.
Click to expand...

Two criterai built in. One is to look for the data in the program folder
then to User Uettings but, at this point, we haven't defined any User
Settings the User can use, er, change.

Sorry, that was an awful sentence.
3. Search in registry for "a:". Maybe you will find something related (a
search path of a program etc).
Click to expand...

Good idea.

Thank you.
 
Does the VB program stand alone from the Access database. If so, how do
you tell VB where the database is?
Click to expand...

Yes, right now it is alone shipped with a empty DB and empty Backup DB. It
is told to look in the install directory C\ProgramFiles\Scheduler. [...]
I open the program and it immediately spins up the A: drive and when any
other function is called, same thing.
Click to expand...

You can select a standard directory for databases inside Access (Options
menu). It totally escapes me why one needs to have a database open just
to change options. But because of this fact you have to open another
database or create a new one to check (and maybe change) this path.
(Maybe it is pointing to an invalid direction [=invalid directory name].)

Next thing to check (besides the things you have already read in other
posts of this thread) is the way, the above mentioned path is used.
It is possible, that one part of this whole conglomerate (setup, program,
database engine) uses a system variable which will be looked up from the
registry (like CSIDL_PROGRAMS / %Program_Files%). In this case you have
to check whether it points to a valid path (and if it is the right one).

And there is still the possibility that one of these components
transcribes long path names to short ones and looks for a directory
C:\Progra~1\Schedu~1 while your directory is C:\Progra~1\Schedu~4
or C:\Progra~2\Schedu~3. That can be the case because of older
installations. (Which even might be deleted by now.)

To bring this back from general help to freeware. There is an excellent
way to hunt this kind of problems down. Use FileMon from SysInternals:

http://www.sysinternals.com/ntw2k/source/filemon.shtml

Anyhow, I think the problem *must* have something to do with an
*invalid* path. That's the main reason for Windows to rattle through
all your drives, including the floppy...

BeAr
 
Does the VB program stand alone from the Access database. If so, how do
you tell VB where the database is?
Click to expand...

Yes, right now it is alone shipped with a empty DB and empty Backup DB. It
is told to look in the install directory C\ProgramFiles\Scheduler. [...]
I open the program and it immediately spins up the A: drive and when any
other function is called, same thing.
Click to expand...

You can select a standard directory for databases inside Access (Options
menu). It totally escapes me why one needs to have a database open just
to change options. But because of this fact you have to open another
database or create a new one to check (and maybe change) this path.
(Maybe it is pointing to an invalid direction [=invalid directory name].)
Click to expand...

I don't understand about the "options" piece, BeAr. The program is opened
and a calendar appears. Click on a date, or pull down and select a menu, to
add, edit, etc. There are no options, as such and all the user data is in
Access.
Next thing to check (besides the things you have already read in other
posts of this thread) is the way, the above mentioned path is used.
It is possible, that one part of this whole conglomerate (setup, program,
database engine) uses a system variable which will be looked up from the
registry (like CSIDL_PROGRAMS / %Program_Files%). In this case you have
to check whether it points to a valid path (and if it is the right one).
Click to expand...

Yeah, makes sense. what doesn't make sense is that I never had this problem
before, can't replicate it and how the whole darn thing got to checking the
floppy drive in the first place.
And there is still the possibility that one of these components
transcribes long path names to short ones and looks for a directory
C:\Progra~1\Schedu~1 while your directory is C:\Progra~1\Schedu~4
or C:\Progra~2\Schedu~3. That can be the case because of older
installations. (Which even might be deleted by now.)
Click to expand...

Okay, I see now.
To bring this back from general help to freeware. There is an excellent
way to hunt this kind of problems down. Use FileMon from SysInternals:

http://www.sysinternals.com/ntw2k/source/filemon.shtml

Anyhow, I think the problem *must* have something to do with an
*invalid* path. That's the main reason for Windows to rattle through
all your drives, including the floppy...

BeAr
Click to expand...

I agree and one of the things that I was trying to find out is if my
machine, the OS or some other non application setting, a system setting
perhaps, that somehow got tied to the software, would do this.

This is, for those who might be in my shoes or contemplating sponsoring
free/software, is one of the problems, I can't write code, some DOS maybe,
so I am at a disadvantage from a technical standpoint.

Much appreciate the help.
 
You can select a standard directory for databases inside Access (Options
menu). It totally escapes me why one needs to have a database open just
to change options. But because of this fact you have to open another
database or create a new one to check (and maybe change) this path.
(Maybe it is pointing to an invalid direction [=invalid directory name].)
Click to expand...

I don't understand about the "options" piece, BeAr. The program is opened
and a calendar appears. Click on a date, or pull down and select a menu, to
add, edit, etc. There are no options, as such and all the user data is in
Access.
Click to expand...

It's not something set inside the 'Scheduler/payroll' program itself,
but inside MS Access. I assume you have MS Office Prof. (or MS Access
alone) installed. So you have to start up MS Access independently from
the scheduler program, open a new or existing *.mdb database and control
the options (inside the tools menu).

If you just have the runtime: There might be somewhere a possibility to
change the standard directory for accessing databases, too. But it has
been years ago that I had to deal with runtimes of Access. So you need
to look for yourself or ask within a MS Access group for help...

BeAr
 
You can select a standard directory for databases inside Access (Options
menu). It totally escapes me why one needs to have a database open just
to change options. But because of this fact you have to open another
database or create a new one to check (and maybe change) this path.
(Maybe it is pointing to an invalid direction [=invalid directory name].)
Click to expand...

I don't understand about the "options" piece, BeAr. The program is opened
and a calendar appears. Click on a date, or pull down and select a menu, to
add, edit, etc. There are no options, as such and all the user data is in
Access.
Click to expand...

It's not something set inside the 'Scheduler/payroll' program itself,
but inside MS Access. I assume you have MS Office Prof. (or MS Access
alone) installed.
Click to expand...

Correct. An empty Access DB is installed in the program folder along with
the exe and the install log.
So you have to start up MS Access independently from
the scheduler program, open a new or existing *.mdb database and control
the options (inside the tools menu).
Correct.

If you just have the runtime: There might be somewhere a possibility to
change the standard directory for accessing databases, too. But it has
been years ago that I had to deal with runtimes of Access. So you need
to look for yourself or ask within a MS Access group for help...

BeAr
Click to expand...

Will do and thanks again.
 
Back
Top