I am having problems with my database not responding to calls for it to open.
I believe my problem is coming from my security settings and the
Record-Locking .ldb files created when a user opens the database.

I have a read-only application with a Front End (FE) and Back End (BE)
sitting in the same shared network folder. We are running XP and using
Access 2003.

The network folder user permissions are Read & execute; List folders; Read &
Write. The FE and BE file permissions are inherited.

Same FE for everyone
Understanding it goes against my understanding and universal thought of how
a FE should be used – I’ve been told I am not able to place copies of my
application on our organizations desktops. I was given only one option; use
a shortcut from desktops that will open the database sitting on a shared
network folder. So we’ve placed a desktop shortcut on everyone’s desktop and
my fears are coming true; unresponsive shortcut – meaning the database is
locked up. At times there are more than a single user accessing the database
– but most of the time – not so much.

A little more about the application
Our application is strictly read only. Users access the FE an navigate
through a couple of informational pages to a search page. From there they
can search for a specific record, click on the record opening a Form
containing information about a record and may have a couple of hyperlinks to
web resources. In addition the user may choose to print this Form or a
report consisting of numerous records. The FE is a completely locked down
and highly secured .mde file - No data is input, no scrolling, no nothing.
This is just a read-only database.

I’m trying to find a way of getting rid of the Record-Locking .ldb file as I
don’t believe it is necessary in my read-only situation. I would appreciate
any suggestions as to how I can improve user interactivity while using a
single FE on the network.

Thank you,
Bill

Don't know how many users you have, is there any possibility of putting one
copy for each user (of the frontend) on the server?


Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia


"BillA" <(E-Mail Removed)> wrote in message
news:77F96C96-F7E7-4D90-89C6-(E-Mail Removed)...
>I am having problems with my database not responding to calls for it to
>open.
> I believe my problem is coming from my security settings and the
> Record-Locking .ldb files created when a user opens the database.
>
> I have a read-only application with a Front End (FE) and Back End (BE)
> sitting in the same shared network folder. We are running XP and using
> Access 2003.
>
> The network folder user permissions are Read & execute; List folders; Read
> &
> Write. The FE and BE file permissions are inherited.
>
> Same FE for everyone
> Understanding it goes against my understanding and universal thought of
> how
> a FE should be used - I've been told I am not able to place copies of my
> application on our organizations desktops. I was given only one option;
> use
> a shortcut from desktops that will open the database sitting on a shared
> network folder. So we've placed a desktop shortcut on everyone's desktop
> and
> my fears are coming true; unresponsive shortcut - meaning the database is
> locked up. At times there are more than a single user accessing the
> database
> - but most of the time - not so much.
>
> A little more about the application
> Our application is strictly read only. Users access the FE an navigate
> through a couple of informational pages to a search page. From there they
> can search for a specific record, click on the record opening a Form
> containing information about a record and may have a couple of hyperlinks
> to
> web resources. In addition the user may choose to print this Form or a
> report consisting of numerous records. The FE is a completely locked down
> and highly secured .mde file - No data is input, no scrolling, no nothing.
> This is just a read-only database.
>
> I'm trying to find a way of getting rid of the Record-Locking .ldb file as
> I
> don't believe it is necessary in my read-only situation. I would
> appreciate
> any suggestions as to how I can improve user interactivity while using a
> single FE on the network.
>
> Thank you,
> Bill

Hello Jeanette,

Placing additional copies on the server wouldn't be feasible - we've only
rolled it out to a possible 500 user of a total of more than 2500 with
locations disbursed around our state. Reason to slow roll this application
to our workforce was to keep the interest factor down and keep any possible
access problems minimized. Eventually this application is meant to be a
organization tool that will be used infrequently by a minority group of users
- but will be available to all.

Thank you for your interest.
Bill

"Jeanette Cunningham" wrote:

> Don't know how many users you have, is there any possibility of putting one
> copy for each user (of the frontend) on the server?
>
>
> Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia
>
>
> "BillA" <(E-Mail Removed)> wrote in message
> news:77F96C96-F7E7-4D90-89C6-(E-Mail Removed)...
> >I am having problems with my database not responding to calls for it to
> >open.
> > I believe my problem is coming from my security settings and the
> > Record-Locking .ldb files created when a user opens the database.
> >
> > I have a read-only application with a Front End (FE) and Back End (BE)
> > sitting in the same shared network folder. We are running XP and using
> > Access 2003.
> >
> > The network folder user permissions are Read & execute; List folders; Read
> > &
> > Write. The FE and BE file permissions are inherited.
> >
> > Same FE for everyone
> > Understanding it goes against my understanding and universal thought of
> > how
> > a FE should be used - I've been told I am not able to place copies of my
> > application on our organizations desktops. I was given only one option;
> > use
> > a shortcut from desktops that will open the database sitting on a shared
> > network folder. So we've placed a desktop shortcut on everyone's desktop
> > and
> > my fears are coming true; unresponsive shortcut - meaning the database is
> > locked up. At times there are more than a single user accessing the
> > database
> > - but most of the time - not so much.
> >
> > A little more about the application
> > Our application is strictly read only. Users access the FE an navigate
> > through a couple of informational pages to a search page. From there they
> > can search for a specific record, click on the record opening a Form
> > containing information about a record and may have a couple of hyperlinks
> > to
> > web resources. In addition the user may choose to print this Form or a
> > report consisting of numerous records. The FE is a completely locked down
> > and highly secured .mde file - No data is input, no scrolling, no nothing.
> > This is just a read-only database.
> >
> > I'm trying to find a way of getting rid of the Record-Locking .ldb file as
> > I
> > don't believe it is necessary in my read-only situation. I would
> > appreciate
> > any suggestions as to how I can improve user interactivity while using a
> > single FE on the network.
> >
> > Thank you,
> > Bill
>
>
> .
>

"BillA" <(E-Mail Removed)> wrote in message
news:77F96C96-F7E7-4D90-89C6-(E-Mail Removed)...
>
> Same FE for everyone
> Understanding it goes against my understanding and universal thought of
> how
> a FE should be used – I’ve been told I am not able to place copies of my
> application on our organizations desktops.
>

Depending on your organisation's IT policy, you might be able to deploy your
FE to the users' Temp folder in their profile. It's a method I use all the
time and it works by copying the FE file to the user's Temp folder on
demand, so only the users that want it get it.

The user's shortcut points to a batch file, an example of which follows
(A2003), hope it helps.

Keith.
www.keithwilby.co.uk

ECHO OFF

DEL "%temp%\FEFolder\*.*" /Q
RD "%temp%\FEFolder"
MKDIR "%temp%\FEFolder"

DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"

XCOPY "X:\MyPath\MyFE.mde" "%temp%\FEFolder" /I
START "MyApp" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
"%temp%\FEFolder\MyFE.mde" /wrkgrp "X:\MyPath\MyWIF.mdw"

Keith,

BRILLIANT!
I must say I would not have thought of this tactic. Now to sell it to our
dogmatic IT department.

One question; if I want the user to open the application from a shortcut
placed on their desktop, would I need to delete and reinsert a shortcut;

DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"

Maybe you could tell me the intent of this section of this script?

Your suggestion has given me so many ideas.

I’ll write back and let you know how ‘IT’ goes.

Thank you!
Bill


"Keith Wilby" wrote:

> "BillA" <(E-Mail Removed)> wrote in message
> news:77F96C96-F7E7-4D90-89C6-(E-Mail Removed)...
> >
> > Same FE for everyone
> > Understanding it goes against my understanding and universal thought of
> > how
> > a FE should be used – I’ve been told I am not able to place copies of my
> > application on our organizations desktops.
> >
>
> Depending on your organisation's IT policy, you might be able to deploy your
> FE to the users' Temp folder in their profile. It's a method I use all the
> time and it works by copying the FE file to the user's Temp folder on
> demand, so only the users that want it get it.
>
> The user's shortcut points to a batch file, an example of which follows
> (A2003), hope it helps.
>
> Keith.
> www.keithwilby.co.uk
>
> ECHO OFF
>
> DEL "%temp%\FEFolder\*.*" /Q
> RD "%temp%\FEFolder"
> MKDIR "%temp%\FEFolder"
>
> DEL "%userprofile%\desktop\MyShortcut.lnk"
> XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"
>
> XCOPY "X:\MyPath\MyFE.mde" "%temp%\FEFolder" /I
> START "MyApp" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
> "%temp%\FEFolder\MyFE.mde" /wrkgrp "X:\MyPath\MyWIF.mdw"
>
> .
>

"BillA" <(E-Mail Removed)> wrote in message
news:105AEBFC-9171-45E1-9F97-(E-Mail Removed)...
> Keith,
>
> BRILLIANT!
> I must say I would not have thought of this tactic. Now to sell it to our
> dogmatic IT department.
>
> One question; if I want the user to open the application from a shortcut
> placed on their desktop, would I need to delete and reinsert a shortcut;
>
> DEL "%userprofile%\desktop\MyShortcut.lnk"
> XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"
>
> Maybe you could tell me the intent of this section of this script?
>
> Your suggestion has given me so many ideas.
>
> I’ll write back and let you know how ‘IT’ goes.
>
> Thank you!
> Bill
>
>
>

Hi Bill. It might be that your users' Temp folders are wide open as are
mine, so you might not need IT's intervention at all. Just see if you can
save a large file to your own and see if it counts towards your profile size
(mine doesn't).

The purpose of the code is to wipe out pre-existing copies of the FE folder
and the desktop shortcut (if they exist) and copy across replacements. That
way your users always get the latest copies on demand. If they don't exist
then the "delete" parts will fail silently.

The lines of code you've singled out delete the desktop shortcut and copy
across its replacement.

You can roll out the shortcut to your users by e-mailing them a hyperlink to
the batch file. Of course, the public folder you use should be readable
(and read-only) to all of your users

Regards,
Keith.
www.keithwilby.co.uk

Hi Keith,

Success running the .bat file, but, there's always a 'but.'

The command prompt window doesn't disappear. And that is due, I believe,
due to the fact that I am trying to use UNC's to path to the proper folders.
I can't get around not using UNC's because everyones mapped directories will
be different. I get this message:
[my folder UNC]
"CMD.EXE was started with the above path as the current directory. UNC
Paths are not supported. Defaulting to Windows directory."

Is there a way of using the UNC to path to the folders

Here is the script I used:

ECHO OFF

DEL "%temp%\DSC_Folder\*.*" /Q
RD "%temp%\DSC_Folder"
MD "%temp%\DSC_Folder"

DEL "%userprofile%\desktop\Data Set Catalog1.lnk"
XCOPY "\\146.243.80.211\shared\Data_Access\Dataset_Catalog\DPH_USER\Data Set
Catalog1.lnk" "%userprofile%\desktop"

XCOPY
"\\146.243.80.211\shared\Data_Access\Dataset_Catalog\DPH_USER\DSC_fe.mde"
"%temp%\DSC_Folder" /I
START "DSC_FE" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
"%temp%\DSC_Folder\DSC_FE.mde"

Thank you for your time & assistance.
Bill


"Keith Wilby" wrote:

> "BillA" <(E-Mail Removed)> wrote in message
> news:105AEBFC-9171-45E1-9F97-(E-Mail Removed)...
> > Keith,
> >
> > BRILLIANT!
> > I must say I would not have thought of this tactic. Now to sell it to our
> > dogmatic IT department.
> >
> > One question; if I want the user to open the application from a shortcut
> > placed on their desktop, would I need to delete and reinsert a shortcut;
> >
> > DEL "%userprofile%\desktop\MyShortcut.lnk"
> > XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"
> >
> > Maybe you could tell me the intent of this section of this script?
> >
> > Your suggestion has given me so many ideas.
> >
> > I’ll write back and let you know how ‘IT’ goes.
> >
> > Thank you!
> > Bill
> >
> >
> >
>
> Hi Bill. It might be that your users' Temp folders are wide open as are
> mine, so you might not need IT's intervention at all. Just see if you can
> save a large file to your own and see if it counts towards your profile size
> (mine doesn't).
>
> The purpose of the code is to wipe out pre-existing copies of the FE folder
> and the desktop shortcut (if they exist) and copy across replacements. That
> way your users always get the latest copies on demand. If they don't exist
> then the "delete" parts will fail silently.
>
> The lines of code you've singled out delete the desktop shortcut and copy
> across its replacement.
>
> You can roll out the shortcut to your users by e-mailing them a hyperlink to
> the batch file. Of course, the public folder you use should be readable
> (and read-only) to all of your users
>
> Regards,
> Keith.
> www.keithwilby.co.uk
>
> .
>

"BillA" <(E-Mail Removed)> wrote in message
news:77FBC0F9-27C1-4AB3-A40D-(E-Mail Removed)...
> Hi Keith,
>
> Success running the .bat file, but, there's always a 'but.'
>
> The command prompt window doesn't disappear. And that is due, I believe,
> due to the fact that I am trying to use UNC's to path to the proper
> folders.
> I can't get around not using UNC's because everyones mapped directories
> will
> be different. I get this message:
> [my folder UNC]
> "CMD.EXE was started with the above path as the current directory. UNC
> Paths are not supported. Defaulting to Windows directory."
>
> Is there a way of using the UNC to path to the folders
>
>

UNCs work fine for me. Have you tried paths without spaces? Not sure what
else to suggest ...

BillA <(E-Mail Removed)> wrote:

>Same FE for everyone
>Understanding it goes against my understanding and universal thought of how
>a FE should be used – I’ve been told I am not able to place copies of my
>application on our organizations desktops. I was given only one option; use
>a shortcut from desktops that will open the database sitting on a shared
>network folder.

How about the users local apps folder then? That's standard practice
to put these kinds of files in that folder. Just the shortcut would
go on the desktop, Quick Launch, or Start >> All Programs.

I see you're already looking at a batch file solution suggested by
Keith to the temp folder. Note that this type of solution will copy
down the new FE every time the user opens the FE. Which can load to
increased startup times and network load. Although not that
significant for a relatively small app such as yours?

As an alternative I'd suggest the Auto FE updater as in my sig below.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/