Network Shortcut Problems

[Guest]

A folder on our network folder contains the following files:
- a database (Access 2000)
- the .mdw security file
- a shortcut to access the database using the security file

All users access the database through the shortcut (although some copy the
shortcut onto their desktop). Periodically, the shortcut target changes to:

"\\jsmith\c$\Program Files\Microsoft Office\Office\MSACCESS.EXE" "[database
path]" "[security path]"

Any ideas why the regular "c:\Program Files\Microsoft
Office\Office\MSACCESS.EXE" . . ." would change? It's annoying to reconfigure

Thanks in advance,

Dustin

 

[Joan Wild]

The shortcut should be on their computer, not on the network folder. It's also recommended that you split the database (split it manually, don't use the splitter wizard). Put just the backend file on the network. Each user's computer would have a copy of the frontend and a shortcut.

Also your target isn't right. It should be "path to msaccess.exe" "path to frontend" /wrkgrp "path to secure mdw"

You are missing the /wrkgrp switch (which, by the way, suggests that your database isn't secured properly).

 

[Guest]

Joan,

Thanks for your response. I realize that there are structural problems with
the setup (no front end / back end split), but that's just how it has to be
to suit our application. The target works fine, I've got a /wrkgrp and even a
/user switch in the line.

I just want to know the [path to msaccess.exe] might switch to
\\username\c$\Program Files. Have you heard of this behaviour before, or does
it never come up because no one uses network shortcuts?

Thanks

Dustin

The shortcut should be on their computer, not on the network folder. It's also recommended that you split the database (split it manually, don't use the splitter wizard). Put just the backend file on the network. Each user's computer would have a copy of the frontend and a shortcut.

Also your target isn't right. It should be "path to msaccess.exe" "path to frontend" /wrkgrp "path to secure mdw"

You are missing the /wrkgrp switch (which, by the way, suggests that your database isn't secured properly).

--
Joan Wild
Microsoft Access MVP

A folder on our network folder contains the following files:
- a database (Access 2000)
- the .mdw security file
- a shortcut to access the database using the security file

All users access the database through the shortcut (although some copy the
shortcut onto their desktop). Periodically, the shortcut target changes to:

"\\jsmith\c$\Program Files\Microsoft Office\Office\MSACCESS.EXE" "[database
path]" "[security path]"

Any ideas why the regular "c:\Program Files\Microsoft
Office\Office\MSACCESS.EXE" . . ." would change? It's annoying to reconfigure

Thanks in advance,

Dustin

 

[DAVID]

make the shortcut write protected.
make it read only.
remove the write permissions.

AFAIK, Windows always tells you when it is
re-writing your shortcuts: it gives you a
message something like:
'target not found. search for target?'

But you can't depend on your users to
report that kind of problem to you.

(david)

 

[Guest]

So simple, and somewhat obvious.

Thanks, David.

make the shortcut write protected.
make it read only.
remove the write permissions.

AFAIK, Windows always tells you when it is
re-writing your shortcuts: it gives you a
message something like:
'target not found. search for target?'

But you can't depend on your users to
report that kind of problem to you.

(david)

A folder on our network folder contains the following files:
- a database (Access 2000)
- the .mdw security file
- a shortcut to access the database using the security file

All users access the database through the shortcut (although some copy the
shortcut onto their desktop). Periodically, the shortcut target changes to:

"\\jsmith\c$\Program Files\Microsoft Office\Office\MSACCESS.EXE" "[database
path]" "[security path]"

Any ideas why the regular "c:\Program Files\Microsoft
Office\Office\MSACCESS.EXE" . . ." would change? It's annoying to reconfigure

Thanks in advance,

Dustin

 

[Tony Toews [MVP]]

Thanks for your response. I realize that there are structural problems with
the setup (no front end / back end split), but that's just how it has to be
to suit our application.

Why is your application so different?

You are running a greatly increased risk of corruption.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Chris Mills]

Thanks for your response. I realize that there are structural problems with

the setup (no front end / back end split), but that's just how it has to be
to suit our application.

A non-split database will "work" networked with several users, so that is not
your direct problem here.
(I once ran 4 users networked in a similar way for months, and it seemed OK)

But it is universally recommended to run split when networked/multiuser.
Performance is easy enough to understand (moving the program portion local to
each user MUST reduce network traffic). Corruption is an oft-cited issue,
which is harder to "test", but there is universal suspicion that "reduced
network traffic means less corruption" (and that Access seems especially
critical)

(Don't ask me how reliability of the OS/Network works! I thought, corrupted
file reads were detected by the likes of parity or better and re-sent. At the
OS level. Nevertheless, theory being just an amusement, the "macroscopic"
results in Access seem to be universal - corruption happens!)

NO application with shared data Requires to be run unsplit. Certainly there
were VBA procedures (thinking of A2.0) which did not run on linked tables.
Tables had to be changed to Recordsets in VBA code I think (but I must be an
elephant to remember that).

I cannot think of any other reason - maybe there is - in which case change out
those reasons at the first opportunity!

Actually I can think of a reason. If it's inherited unsplit (the recipient
might not be sure of all the splitting implications to do with the code), then
it COULD take quite a bit of testing etc. I inherited just such an app where
this was true. It was passed on again before I got to splitting it <g>

Whilst the shortcut issue seems to be resolved, I would have a separate
shortcut on each PC, EVEN IF it's to the same, shared, unsplit, unrecommended,
database. For one thing, the program msaccess.exe is still local to each
machine, and a shared shortcut would assume msaccess is in the same place on
each local machine...but it isn't unless you verify if it is.

The workgroup file has to be shared via the network, that is, in order to have
a password change reflected at all machines. If passwords/users are never
gonna be changed, there can be multiple copies of the mdw. I agree this is an
outright lazy option (but suits, for example, some limitations of PDW
installer!)

Only send me 2c if you're excessively generous
Chris

 

[Tony Toews [MVP]]

A non-split database will "work" networked with several users, so that is not
your direct problem here.
(I once ran 4 users networked in a similar way for months, and it seemed OK)

Access 97 was much more stable in this regard. I still had some
corruptions though.

(Don't ask me how reliability of the OS/Network works! I thought, corrupted
file reads were detected by the likes of parity or better and re-sent. At the
OS level. Nevertheless, theory being just an amusement, the "macroscopic"
results in Access seem to be universal - corruption happens!)

I think it's more a matter of the network component OS keeps retrying
to send the data but finally gives up. And Access times out pretty
quickly too. And if only some packets get through then Jet really
has a tough time with things.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

I think it's more a matter of the network component OS keeps
retrying to send the data but finally gives up. And Access times
out pretty quickly too. And if only some packets get through
then Jet really has a tough time with things.

Given the importance of data integrity, I think we *want* Access to
give up quickly, and to never accept or send anything that is even
the slightest bit suspect.

 

[Chris Mills]

I read a white paper on Access Corruption once. Dunno where. Maybe it was a
brown paper Ho-Ho.

The gist of it was, Access sets some internal "busy" flag and resets after the
write(s). If this flag is not reset, the db is marked as "corrupted". But in
99% of the "events" the db is not actually corrupted, just the flag is set.
This certainly seems to be a "safe approach" on The Access Team's part, (if
true).

It's the sort of thing easily reset by running "Repair". Anyway, the above
theory seems consistent with the fact that I can "Repair" databases 99% of the
time. I mean, 99% of the corruption times <heh-heh>.

But why Access is more prone than other files, I sure can't reconcile. I have
never known of a Word Doc being subtly corrupted by the OS (have I not looked
hard enough?). Nowadays it's standard practice to transfer 1.5mb+ digital
camera photos, one wouldn't know if a few pixels were corrupted of course, but
do digital files REALLY degrade? (I Don't Think So, or This Is A Scandal).

More pertinently, I've downloaded up to 65mB from MS website for "program
upgrade". 56k modem. Took all night, other side of the world, had to use
"Gorilla" for many re-starts in the 8 or more hours. One would hope that the
resulting transmission had ZERO errors (quite true so far as I know) because
otherwise I would have been reporting perplexing errors in an Access upgrade!

I derive from that, that Internet Explorer "managed" via "Gorilla!", with
multiple abort/restarts, for 8hrs via flakey phone-lines not to mention
cosmic-rays-hitting-satellites, is EVEN SO more reliable than Access?
(I EXPECT a large transfer to be either completely reliable, or fail. Don't
you?)
----------
OTOH, many years ago (late 80's) my company-at-the-time had a "PC Expert" from
the USA give us a lecture. I always remember him saying (at least about
earlier PC's maybe Clones) "DON'T put an oscilloscope on the Motherboard! If
you do, there is so much noise that you will wonder how it ever works!"
(I still have a Tektronix oscillosope. Those were the days!)
----------
I think "theory" is interesting in an attempt to understand intangibles like
corruption, but perhaps more pertinent is that a newsgroup gives access to a
greater "installed base practical experience", so-to-speak. I can't deny that
"strange things happen sometimes". And I don't "trust" any single operator,
not even myself (beyond reproducible items).

Chris

 

[David W. Fenton]

But why Access is more prone than other files, I sure can't
reconcile. I have never known of a Word Doc being subtly corrupted
by the OS (have I not looked hard enough?).

Because an Access MDB is several orders of magnitude more complex in
its structure than a Word document. Word has only three parts, the
header, the data, and the formatting. There are pointers within the
data that point to the formatting information, and those pointers
can become screwed up, but seldom do. And the data is redundant,
because the UNDO levels are stored within the document and not
discarded unless you take some special actions.

So, there's lots of redundancy.

And even if a few bits are dropped, it's not going to screw up much
of anything.

An Excel file also has lots of redundant information, because the
values that result from calculations are stored, not just the
formulas for the calculations.

But an MDB is not so redundant, and its structure is much, much more
complicated. It's also much more ad hoc, since there's no way of
predicting how many tables and other objects there will be nor where
they will be stored.

Secondly, the data structures within an MDB are highly
inter-related. The index pages have to be in proper alignment with
the data pages they correspond to. The header pages have to be
properly written to keep track of which data pages are in use and
what objects those data pages are allocated to.

It's precisely because of this multi-level pointer-based system for
storing relational data that it's crucial that you are immediately
notified any time anything suspect develops.

In terms of data integrity (not internal file integrity), as I said,
you wouldn't want it any other way. Were it not so, you really
*couldn't* trust data stored in an MDB.