473,320 Members | 1,600 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Can't find MDW file problem

I have a situation where some, not all, users get the message "Couldn't
find file "F:\AccessApps\AppName.mdw". This file is required for startup".

My app the users are attempting to access is written A2003 and they use
the A2003 runtime to access the application. They use a desktop icon
that specifies the location of Access, the Appname, and the MDW file to
use. Ex:
"C:\ProgramFiles\Office\MSACCESS.EXE" "C:\Apps\App.MDB" /wrkgrp
F:\Backend\App.MDW

The only users getting this message have A97 retail, A2000 retail, and
A2003 runtime. All other users have A2003 runtime only on their PCs as
well as Office 2007 products and they do not get this error message.

All users experiencing this problem have WinXP as their OS and all SPs
are up to date. The office version they have is Office 2000 they use
for other Office products like Word and Excel.

These users, if they want to use the program in A2003, must/always log
into the same app in A97 first and then log into the app in A2003. In
all desktop icons the MDW is specified.

At first I thought it might be a "rights" issue but I discarded that
thought since they can log into the app with A2003 if they first open it
(using the same MDW file) in A97.

This problem first cropped up using Tony Toew's AutoFE program. Since I
don't have Tony's source code I couldn't determine if his program or my
program was the source of the problem. I designed another method to
distribute updates and the problem still occurs with my new method.

My temporary kludge fix is to have them run WrkGAdm.EXE and join to the
MDW file on the network. This corrects the problem. This problem
occurs only when I create a new update for them that requires
distribution. After they have "rejoined" the MDW file after a new
update they don't have the problem again until another update is created.

When I do an update, I create the updated version from a machine with a
full version of A2003 attached to their network. I recompile the
application and make an MDE from that machine. This machine is always
attached to the MDW file on their network.

Does anyone have any idea why Access gives this message regarding the
MDW file that is hard-coded/specified in the desktop icon? Why
rejoining is the only solution at this point to solving the problem?

Could this be a registry problem? I am casting a jaundiced eye towards
Office 2000 at this point as the culprit.

Any suggestions are welcome.


Oct 15 '08 #1
4 4004
On Oct 15, 1:57*pm, Salad <o...@vinegar.comwrote:
I have a situation where some, not all, users get the message "Couldn't
find file "F:\AccessApps\AppName.mdw". *This file is required for startup".

My app the users are attempting to access is written A2003 and they use
the A2003 runtime to access the application. *They use a desktop icon
that specifies the location of Access, the Appname, and the MDW file to
use. *Ex:
* *"C:\ProgramFiles\Office\MSACCESS.EXE" "C:\Apps\App.MDB" /wrkgrp
F:\Backend\App.MDW

The only users getting this message have A97 retail, A2000 retail, and
A2003 runtime. *All other users have A2003 runtime only on their PCs as
well as Office 2007 products and they do not get this error message.

All users experiencing this problem have WinXP as their OS and all SPs
are up to date. *The office version they have is Office 2000 they use
for other Office products like Word and Excel.

These users, if they want to use the program in A2003, must/always log
into the same app in A97 first and then log into the app in A2003. *In
all desktop icons the MDW is specified.

At first I thought it might be a "rights" issue but I discarded that
thought since they can log into the app with A2003 if they first open it
(using the same MDW file) in A97.

This problem first cropped up using Tony Toew's AutoFE program. *Since I
don't have Tony's source code I couldn't determine if his program or my
program was the source of the problem. *I designed another method to
distribute updates and the problem still occurs with my new method.

My temporary kludge fix is to have them run WrkGAdm.EXE and join to the
MDW file on the network. *This corrects the problem. *This problem
occurs only when I create a new update for them that requires
distribution. *After they have "rejoined" the MDW file after a new
update they don't have the problem again until another update is created.

When I do an update, I create the updated version from a machine with a
full version of A2003 attached to their network. *I recompile the
application and make an MDE from that machine. *This machine is always
attached to the MDW file on their network.

Does anyone have any idea why Access gives this message regarding the
MDW file that is hard-coded/specified in the desktop icon? *Why
rejoining is the only solution at this point to solving the problem?

Could this be a registry problem? *I am casting a jaundiced eye towards
Office 2000 at this point as the culprit.

Any suggestions are welcome.
Does it make any difference if you specify the \wrkgrp parameter
before the name of the .mdb file, i.e.

"C:\ProgramFiles\Office\MSACCESS.EXE" /wrkgrp "F:\Backend\App.MDW" "C:
\Apps\App.MDB"

Also, what do you have in the 'Start in:' field of the shortcut
properties?

Bruce
Oct 15 '08 #2
BruceB wrote:
On Oct 15, 1:57 pm, Salad <o...@vinegar.comwrote:
>>I have a situation where some, not all, users get the message "Couldn't
find file "F:\AccessApps\AppName.mdw". This file is required for startup".

My app the users are attempting to access is written A2003 and they use
the A2003 runtime to access the application. They use a desktop icon
that specifies the location of Access, the Appname, and the MDW file to
use. Ex:
"C:\ProgramFiles\Office\MSACCESS.EXE" "C:\Apps\App.MDB" /wrkgrp
F:\Backend\App.MDW

The only users getting this message have A97 retail, A2000 retail, and
A2003 runtime. All other users have A2003 runtime only on their PCs as
well as Office 2007 products and they do not get this error message.

All users experiencing this problem have WinXP as their OS and all SPs
are up to date. The office version they have is Office 2000 they use
for other Office products like Word and Excel.

These users, if they want to use the program in A2003, must/always log
into the same app in A97 first and then log into the app in A2003. In
all desktop icons the MDW is specified.

At first I thought it might be a "rights" issue but I discarded that
thought since they can log into the app with A2003 if they first open it
(using the same MDW file) in A97.

This problem first cropped up using Tony Toew's AutoFE program. Since I
don't have Tony's source code I couldn't determine if his program or my
program was the source of the problem. I designed another method to
distribute updates and the problem still occurs with my new method.

My temporary kludge fix is to have them run WrkGAdm.EXE and join to the
MDW file on the network. This corrects the problem. This problem
occurs only when I create a new update for them that requires
distribution. After they have "rejoined" the MDW file after a new
update they don't have the problem again until another update is created.

When I do an update, I create the updated version from a machine with a
full version of A2003 attached to their network. I recompile the
application and make an MDE from that machine. This machine is always
attached to the MDW file on their network.

Does anyone have any idea why Access gives this message regarding the
MDW file that is hard-coded/specified in the desktop icon? Why
rejoining is the only solution at this point to solving the problem?

Could this be a registry problem? I am casting a jaundiced eye towards
Office 2000 at this point as the culprit.

Any suggestions are welcome.


Does it make any difference if you specify the \wrkgrp parameter
before the name of the .mdb file, i.e.

"C:\ProgramFiles\Office\MSACCESS.EXE" /wrkgrp "F:\Backend\App.MDW" "C:
\Apps\App.MDB"
I will have to check that one out. What would you recommend...the
folder that MS-Access.EXE is in or the folder where the MDB is in?
Also, what do you have in the 'Start in:' field of the shortcut
properties?
I really don't know. I'll check that out tho I don't know why it would
make a difference.
Bruce
Oct 15 '08 #3
On Oct 15, 5:22*pm, Salad <o...@vinegar.comwrote:
BruceB wrote:
On Oct 15, 1:57 pm, Salad <o...@vinegar.comwrote:
>I have a situation where some, not all, users get the message "Couldn't
find file "F:\AccessApps\AppName.mdw". *This file is required for startup".
>My app the users are attempting to access is written A2003 and they use
the A2003 runtime to access the application. *They use a desktop icon
that specifies the location of Access, the Appname, and the MDW file to
use. *Ex:
* "C:\ProgramFiles\Office\MSACCESS.EXE" "C:\Apps\App.MDB" /wrkgrp
F:\Backend\App.MDW
>The only users getting this message have A97 retail, A2000 retail, and
A2003 runtime. *All other users have A2003 runtime only on their PCs as
well as Office 2007 products and they do not get this error message.
>All users experiencing this problem have WinXP as their OS and all SPs
are up to date. *The office version they have is Office 2000 they use
for other Office products like Word and Excel.
>These users, if they want to use the program in A2003, must/always log
into the same app in A97 first and then log into the app in A2003. *In
all desktop icons the MDW is specified.
>At first I thought it might be a "rights" issue but I discarded that
thought since they can log into the app with A2003 if they first open it
(using the same MDW file) in A97.
>This problem first cropped up using Tony Toew's AutoFE program. *Since I
don't have Tony's source code I couldn't determine if his program or my
program was the source of the problem. *I designed another method to
distribute updates and the problem still occurs with my new method.
>My temporary kludge fix is to have them run WrkGAdm.EXE and join to the
MDW file on the network. *This corrects the problem. *This problem
occurs only when I create a new update for them that requires
distribution. *After they have "rejoined" the MDW file after a new
update they don't have the problem again until another update is created.
>When I do an update, I create the updated version from a machine with a
full version of A2003 attached to their network. *I recompile the
application and make an MDE from that machine. *This machine is always
attached to the MDW file on their network.
>Does anyone have any idea why Access gives this message regarding the
MDW file that is hard-coded/specified in the desktop icon? *Why
rejoining is the only solution at this point to solving the problem?
>Could this be a registry problem? *I am casting a jaundiced eye towards
Office 2000 at this point as the culprit.
>Any suggestions are welcome.
Does it make any difference if you specify the \wrkgrp parameter
before the name of the .mdb file, i.e.
"C:\ProgramFiles\Office\MSACCESS.EXE" /wrkgrp "F:\Backend\App.MDW" "C:
\Apps\App.MDB"

I will have to check that one out. *What would you recommend...the
folder that MS-Access.EXE is in or the folder where the MDB is in?
Also, what do you have in the 'Start in:' field of the shortcut
properties?

I really don't know. * I'll check that out tho I don't know why it would
make a difference.
Bruce
I would experiment with specifying the /wrkgrp parameter first, and
try different values for the 'start in' property of the shortcut,
i.e., try starting it in f:\backend, c:\program files\office, and c:
\apps, see if any of those correct the problem. It's a shot in the
dark, I admit.

Bruce
Oct 21 '08 #4
BruceB wrote:
On Oct 15, 5:22 pm, Salad <o...@vinegar.comwrote:
>>BruceB wrote:
>>>On Oct 15, 1:57 pm, Salad <o...@vinegar.comwrote:
>>>>I have a situation where some, not all, users get the message "Couldn't
find file "F:\AccessApps\AppName.mdw". This file is required for startup".
>>>>My app the users are attempting to access is written A2003 and they use
the A2003 runtime to access the application. They use a desktop icon
that specifies the location of Access, the Appname, and the MDW file to
use. Ex:
"C:\ProgramFiles\Office\MSACCESS.EXE" "C:\Apps\App.MDB" /wrkgrp
F:\Backend\App.MDW
>>>>The only users getting this message have A97 retail, A2000 retail, and
A2003 runtime. All other users have A2003 runtime only on their PCs as
well as Office 2007 products and they do not get this error message.
>>>>All users experiencing this problem have WinXP as their OS and all SPs
are up to date. The office version they have is Office 2000 they use
for other Office products like Word and Excel.
>>>>These users, if they want to use the program in A2003, must/always log
into the same app in A97 first and then log into the app in A2003. In
all desktop icons the MDW is specified.
>>>>At first I thought it might be a "rights" issue but I discarded that
thought since they can log into the app with A2003 if they first open it
(using the same MDW file) in A97.
>>>>This problem first cropped up using Tony Toew's AutoFE program. Since I
don't have Tony's source code I couldn't determine if his program or my
program was the source of the problem. I designed another method to
distribute updates and the problem still occurs with my new method.
>>>>My temporary kludge fix is to have them run WrkGAdm.EXE and join to the
MDW file on the network. This corrects the problem. This problem
occurs only when I create a new update for them that requires
distribution. After they have "rejoined" the MDW file after a new
update they don't have the problem again until another update is created.
>>>>When I do an update, I create the updated version from a machine with a
full version of A2003 attached to their network. I recompile the
application and make an MDE from that machine. This machine is always
attached to the MDW file on their network.
>>>>Does anyone have any idea why Access gives this message regarding the
MDW file that is hard-coded/specified in the desktop icon? Why
rejoining is the only solution at this point to solving the problem?
>>>>Could this be a registry problem? I am casting a jaundiced eye towards
Office 2000 at this point as the culprit.
>>>>Any suggestions are welcome.
>>>Does it make any difference if you specify the \wrkgrp parameter
before the name of the .mdb file, i.e.
>>>"C:\ProgramFiles\Office\MSACCESS.EXE" /wrkgrp "F:\Backend\App.MDW" "C:
\Apps\App.MDB"

I will have to check that one out. What would you recommend...the
folder that MS-Access.EXE is in or the folder where the MDB is in?

>>>Also, what do you have in the 'Start in:' field of the shortcut
properties?

I really don't know. I'll check that out tho I don't know why it would
make a difference.

>>>Bruce


I would experiment with specifying the /wrkgrp parameter first, and
try different values for the 'start in' property of the shortcut,
i.e., try starting it in f:\backend, c:\program files\office, and c:
\apps, see if any of those correct the problem. It's a shot in the
dark, I admit.

Bruce
Thanks Bruce. I decided to remove the reference to the MDW entirely (it
doesn't seem to be used much in A2007. In my app the login was solely
used the login name for determining the currentuser and with A2003 I
updated to UserRoster to get the PC names of active users. I'll find
out tomorrow if it all works.

The error you are responding to is such an esoteric error although one
can see others have had the same problem if your search google.
Personally, I think it was the way O2K was installed...it may be they
used the same "root" folder that A97 was in when they installed A2K and
perhaps that confuses Access.
Oct 21 '08 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Peter Hansen | last post by:
Greetings. Im trying to write a program that can be run from the command line. If I want to search for example after a file with the ending .pdf, I should be able to write in the command line:...
2
by: Abe | last post by:
I have a strange Perl problem I don't understand. I've written the following program to scan different disks on a Windows server to look for directory files. Works fine until it gets to 'e:' when...
2
by: Bob Morrow | last post by:
Frustrating problem. I have a .dll that is called by all the .NET programs that we are developing. The dll reads an .ini file to determine if it should fill a data dictionary from the...
3
by: Karen Grube | last post by:
Hi! Each week, we receive a two-page PDF file from UPS along with a separate flat file (a CSV) The PDF file contains the overview of our weekly invoice and the CSV contains the details of each...
3
by: Siv | last post by:
Hi, A little while ago I wrote a small program that allowed the user to view products from a database. The database holds the details of the products which can be viewed via a form and...
0
by: georges the man | last post by:
The purpose: • Sorting and Searching • Numerical Analysis Design Specification You are to write a program called “StockAnalyser”. Your program will read a text file that contains historical...
6
by: Mudcat | last post by:
Hi, I can't figure out why ctypes won't load the DLL I need to use. I've tried everything I can find (and the ctypes website is down at the moment). Here's what I've seen so far. I've added...
0
by: sndive | last post by:
I have a weid problem. If i do this: import elementtree.ElementTree as ET .... tree = ET.parse("whatever") root = tree.getroot() r = root.find('last') print r return root where last is not an...
8
by: john6630 | last post by:
I am trying to get PDO for sqlite to work on my localhost system. I have modified the PHP5.ini file as shown below and run the following PHP script. As stated below, it reports the mssql, mysql and...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.